On Thu, Jun 18, 2009 at 7:20 AM, David Given
<dg@cowlark.com> wrote:
Miles Bader wrote:
[...]
The main drawback is that not every package is available, and you have
to <do something else> for those that aren't. Maybe run luarocks, but
native debian packages probably have a big advantage for packages which
require non-Lua components.
The obvious thing to do here is to enhance LuaRocks so that it'll generate compliant Debian, Red Hat etc packages. That way LuaRocks simply becomes Debian and Red Hat's official source for the packages, which means they all get built automatically and end up in the archives.
It's probably worth mentioning that as a Debian and Ubuntu user, I don't *want* to use LuaRocks, for exactly the same reason that I don't use CPAN or RubyGems etc. It's too much hassle. Not LuaRocks itself, but managing the composite system of some Debian packages and some manually installed packages is simply more trouble than it's worth. On the rare occasions I'm working on a project which needs a library that's not in Debian I'll usually just copy the source for the library into my project. It's just easier that way, and it's certainly easier on my users...
(Not that I'm denigrating the work that's gone into LuaRocks. It's a great thing to have. It's just I'm not in LuaRocks' audience, because I live in a different ecosystem than LuaRocks was designed for.)
I don't think I could say it any better. These are my exact thoughts.
