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
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.
Some of the flexibility that LuaRocks provides, however, is lost, but
it may not be a problem for them, since it's a kind of flexibility
that is not present in their packaging systems to start with. On the
other hand, for those who need this flexibility, LuaRocks has proven
to be a valuable tool, so dismissing it as a bad idea or unnecessary
diversity is, in my opinion, premature judgement.