Gems and repackaging, hopefully helpful

On Thu, Sep 29, 2005 at 09:46:45AM +0900, Jim Weirich wrote:
> On Wednesday 28 September 2005 07:35 pm, Mauricio Fern?ndez wrote:
> > *  These issues affect all the systems that don't manage Ruby packages
> >    the way RubyGems does it (most predate it). I'm being told so
> >    by Debian, PLD and Suse developers (I haven't been able to get in touch
> >    with other repackagers yet). I was also told so by a FreeBSD
> >    developer, but at least one FreeBSD developer disagrees with him or
> >    thinks that wrapping gem install is an acceptable compromise for the
> >    system.

This has, as far as I can tell (checking mailing lists etc), been
done without appropriate discussion.  The ports break our guidelines for
directory layout, probably for practical reasons (it's hard to fix the layout,
see below).  I have asked for an official statement about the situation from the
appropriate group in FreeBSD, with the FreeBSD ruby-gems maintainer in the loop.

> It is important to differentiate between the gems runtime and the gems package 
> format.  AFAIK, there is nothing in the package format that makes it any 
> worse than, say a tar file.  Yes, there are things to make it even easier 
> (e.g. more metadata, better identification of arch dependent vs arch 
> independent files), but it seems to me that starting with a gem should be 
> easier than starting with a raw tar file.

OK, let me try to make the problem as I see it as clear as I can:

First of all, the comparison with a raw tar file is inappropriate.  Packagers
basically never work with really raw tar files - we work with tar files that
include some installer system, be that a "setup.rb" file or a configure
script generated by autoconf or a homemade system based on Rakefiles or something
else entirely.  There's always some install system we hook upon, and the question
is what assumptions this install system make the software developer make.

In RubyGems guarantee the Gem author that the Gem will be installed with all the
directories placed in a particular fashion compared to each other, including
extra data space.  This assumption is transferred into the code for the project,
where the authors tend to use relative paths etc to get at other files in the
same project.

This makes it difficult (impractical) to re-arrange the directories
when things are installed, as we would have to maintain an extensive patchset
for parts that are often changed, and where it is easy to miss something.

> Take the rake project for example.  Rake is distributed as both a gem and a 
> tar file.  Given that the same software is delivered in both package formats, 
> would you prefer to start with the tar file?  And if so, why?  What specific 
> changes would make it easier for repackagers?

Stop guaranteeing that things are installed in a single directory, and work with
more stringent metadata instead.  Specific references for specific subdirectories,
to be able to *both* generate as a single directory (necessary for e.g. Gentoo)
*and* generate spread out, with readable data under libdata/, variable data under
/var, etc.

This is a significant change, with implications for many gems, which is why I've
tried to push this for a long time (from when there were much fewers gems and
much fewer authors affected.)

Eivind.