Re: Gems and repackaging, hopefully helpful

On Sat, Oct 01, 2005 at 01:40:23AM +0900, David A. Black wrote:
> Hi --
> 
> On Sat, 1 Oct 2005, Eivind Eklund wrote:
> 
> >The most important is being able to install binaries under $prefix/bin/,
> >documentation under doc/<portname>/, examples under examples/<portname>,
> >configuration under etc/, data under share/<portname> or similar,
> >put databases under /var/<suitable location>, and put man/info pages
> >under man/info respectively.  (Hopefully, nobody use info with a
> >RubyGem, though.)  Prefix is /usr/local unless the user has set it 
> >differently.
> >
> >"Full" text below for convenience (I've cut down the hier manpage
> >to be less noisy, only containing relevant directories):
> 
> [snip]
> 
> I respectfully suggest that the landscape of this discussion is
> getting too cluttered.  Since arbitrarily many "repackaging"
> philosophies and systems are possible, the specifics of this or that
> particular system won't have a direct bearing on how a Gem can be
> unpacked and reassembled.   I think it's more a matter of just having
> Gems abstract their layout slightly (or make that possible), and then
> having each repackaging person/team decide how they want to put the
> Gem back together.

I agree with half of this: It is a question of having gems abstract the layout
and making it possible to install the gems under the different policies.

> Or... maybe there could be an intermediate format, to which Gems could
> be converted, that was sufficiently abstract to allow conversion to
> other formats (a kind of hub-and-spoke approach).

If this was possible, the intermediate format wouldn't be necessary :-)
To make this possible, Gems needs to get the necessary abstraction and
metadata, making it possible to do the conversions to other formats
without a lot of manual work to add the abstraction and metadata.

The question is precisely what metadata and abstraction RubyGems needs to
make it possible to do these conversions automatically (or at least
with an amount of manual work that it is feasible to expect.)

I think the way to find out is to look at the systems to convert to.
There's only four major systems available:
- The traditional Unix way.  This follows a set of closely related
  directory layout systems, represented by hier(7) on *BSD, the FHS on
  Linux, and various other standards on other Unix systems.
- The Gentoo/gems way, using a single directory.
- The Windows way, which is mostly a single directory + overwrite
  of system libraries ad hoc.
- The MacOSX way.  This is some kind of bundling with an (to me)
  unknown directory spread.

I think the Unix way is what has most challenges, and I
used the FreeBSD system as an example of this.  Solving for that
would (I believe) get Gems 90% of the way to playing nice with all
repackagers.

Oh, and I would *love* to have Gems auto-convertable to other formats,
with proper support for the other formats.  I think that would be
a big boon for Ruby, and would probably make people package non-Ruby
things using Gems, just for that ability.

Eivind.