Re: Version control systems

[Hisham <hisham.hm@...>]

On Thu, Aug 14, 2008 at 7:27 AM, Enrico Tassi <gareuselesinge@libero.it> wrote:
> On Wed, Aug 13, 2008 at 01:53:05PM -0300, Hisham wrote:
>> On Tue, Aug 12, 2008 at 11:30 PM, Asko Kauppi <askok@dnainternet.net> wrote:
>> >
>> > That's a refreshing point of view, and you might be right.
>>
>> The flaw in the argument is to assume that the native packaging
>> systems are all functionally equivalent and that providing an
>> interface for them is a sufficient solution for the packaging needs of
>> a dynamic language. LuaRocks works in a way that rpm/deb/etc. can't:
>> it resolves dependency versions at require() time, and is designed to
>> allow multiple coexisting versions of packages transparently. Having
>
> This is false, in debian we do have different versions of some packages,
> most notably libraries. They are usually called libfoo23 where 23 is the
> ABI revision, or even libfooVERSION like libssl0.9.8.
>
> So nothing prevents having liblua5.1-lpeg-0.8 as a package name
> (especially if these packages only live in the users filesystem and not
> in the global debian archive that would result too polluted).

We're not in contradiction -- but the operative word in my argument
was "transparently". What I meant is that LuaRocks supports multiple
versions of packages without having to explicitly "branch" the package
and without having upstream support for versioning, which C libraries
usually have by default with the .so.x.y naming convention (or tweaks
such as renaming binaries -- notably, LuaRocks also currently has
limitations in this regard). I'm not arguing that one approach is
inherently better than the other, just that I find the one taken by
LuaRocks to be particularly suitable for dynamic languages (while the
deb approach is certainly more general, which fits a whole-system
management tool).

>> said that, nothing prevents from using LuaRocks as a build tool with
>> the end goal of producing platform-specific packages -- in fact, there
>> has been talk about this in the LuaRocks mailing list, and I find it
>> an excellent route for packagers who wish to provide native packages.
>
> I like the idea of using luarocks to produce debs, but I missed the
> discussion on the mailing list... I'll try to catch up. I had this idea
> many times, but the manifest monolitic-file format always made me delay
> any effort (the manifest should be the result of the merge of all files
> in a directory so that packages can just drop a file in there to inform
> luarocks require that a new version of a package is available).

A possibility would be to use LuaRocks as a build tool (or
build-frontend tool) but take the resulting files and relocate them to
"standard" paths when packing the deb. This would lose the runtime
management provided by LuaRocks but since deb packages would rely on
apt's own package management anyway this might not be a problem. The
upside of this use of LuaRocks would be that various packagers could
share their efforts in encoding build specifics in a compatible way.

-- Hisham