Re: Version control systems

[Enrico Tassi <gareuselesinge@...>]

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).

> 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).

cheers
-- 
Enrico Tassi