Re: Rocks and Debian packages (was: Re: Rocks vs Debian packages (was: How to distribute Boyer-Moore code?))

[Enrico Tassi <gareuselesinge@...>]

On Tue, May 06, 2008 at 12:14:54PM -0300, Hisham wrote:
> Hi,
> 
> First of all, sorry about editing the thread subject yet again, but I
> would never want to get into a "Rocks vs. anything" situation. :-)

Nobody wants it, we all want to be able to use Lua in an effective way
without spending time in setting up a development environment.

Said that, what I was really missing (and what I'm still missing in some
ways) is some sort of blessed collection of libraries. For example we
currently have 3 cURL bindings (I know, writing bindings is easy with
Lua...). My effort in putting Lua inside Debian has a double motivation:
1) be able to type aptitude install liblua5.1-foo to have require 'foo'
working, similar to what luarocks can do. 2) bless some libraries.
Clearly blessing should be done by the whole community first and then by
a selected committee in my opinion, but since I saw no effort in that
direction I abused of Debian for giving some visibility to some
of these libraries I use and like.

> Returning to the developer/packager distinction, I think that from the
> developer side, the most globally helpful course of action is to
> provide good Makefiles, that will work nicely for all packagers. I
> wrote about the main issues here:
> 
> http://www.luarocks.org/en/Recommended_practices_for_Makefiles

In my experience people are not able to write decent Makefiles. I don't
want to be offensive, but despite the good gnu 'make' manual, Makefiles
are usually buggy, and people find make hard. Since 90% of Lua packages
are just few .lua/.c files for the Debian packaging I'm using a 100
lines Makefile that works for all of them and gives me a single place to
eventually fix. Some Debian packages use a common Makefile based system
for handling Debian specific tasks called CDBS (my generic makefiles
will became a CDBS class soon or later) that should grant the same
benefits (a single point of failure/fix/update). An example, on i386 you
can compile without -fPIC and the build a .so library, on amd64 not.
IIRC I reported this bug related to some rocks too... If you use
upstreams Makefile/rocks you will have to fix them all.

My suggestion is a sad "give up trying to teach make" ;-) but feel free
to continue, if you succeed I'll be happy too, I like it!

> In the long run, we expect that other packaging systems will benefit
> from LuaRocks as well, so by making LuaRocks attractive to developers
> we're not competing with other systems, but factoring out work to be
> reused by Debian, Gentoo, Fink, Windows users, etc. We strive to make
> LuaRocks play nice to all packaging systems them and we're cooperating
> with Enrico and other packagers in the LuaRocks mailing list.

I thought many times on how to benefit from .rocks, but it is not that
trivial. Something I should implement is some sort of consistency check
to ensure Debian packages dependencies satisfy the ones declared by
rocks. No time to do that so far... Another idea is to allow luarocks to
build deb packages (instead of installing stuff with cp in /usr/local)
so that rocks are visible to the packaging system of the distribution
(the manifest file could be updated by calling luarocks in postinst and
preremove scripts, and the user could ). But is far from being trivial...

Cheers
-- 
Enrico Tassi