lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> Last year I did some experiments with 'Lua for Linux' which avoided
> Debian-specific stuff. It provided a reasonable core set of libraries
> (without SciTE, it was about a Meg) and LuaRocks for extension.  At
> the time, the response was 'Well why don't you do this using the
> obviously standard apt-get package manager?'.  And the reason I gave
> was that Linux is more than Debian; in fact, Unix is more than LInux,
> so I started thinking about 'Lua for Unix' and got a build going on OS
> X as well.
> The _big_ advantage of a Debian-focussed distro is that the external
> dependencies can be expressed in terms of other Debian packages,
> something that LuaRocks can only give hints about.
    Right. Most Unix package managers really benefit from knowing the
complete graph of installed packages. When the installer for a
language works in isolation (particularly one that also installs C
libraries), it can create quite a mess. I've done some OpenBSD ports
for Lua libraries, and for my purposes it works far better than using
LuaRocks. (There is probably an even bigger mismatch between LuaRocks
and OS package managers that aren't source based.)

It may work to have the OS packaging system call LuaRocks to install,
but handle any dependencies itself. Doing OS-local configuration and
patching at build time would probably be harder, though.