From: Chad Fowler <chadfowler@...>
Date: 2004-10-06T22:48:07+09:00
Subject: Re: RubyGems and RPA

On Tue, 5 Oct 2004 20:09:10 +0900, Eivind Eklund <eeklund@gmail.com> wrote:
> RubyGems are presently somewhat troublesome to repackage (due to
> containing too little policy to be able to fit with requirements from
> other systems - the problems are directory structure and require_gem),
> but this will hopefully be fixed in the future, as a part of RubyGems
> goal of being the "standard" packaging system for authors (and the
> only release they need to do.)  For the time being, repackagers
> request that developers also release as .tar.gz or similar.
> 

I'm surprised to hear you say this.  .tar.gz files contain _less_
policy than RubyGems.  And less metadata.  I'm sure there are _some_
scenarios where gem authors might do something that makes RPA's job a
little harder, but I would guess that in most cases, thinking about a
package management system will cause them to solve some of the
problems that would have to be solved for RPA.  An example is Austin's
work on gem/rpa-ifying Ruwiki, which has required him to change things
about how Ruwiki works.

To accomodate both systems in a package-management-system-neutral way
will probably require additional "standard" abstractions that
packagers and authors can rely on just being there (included with the
ruby distribution, probably).  The only way to really find out is to
create more packages.

I'd love to collect specific examples (on a Wiki--not ruby-talk) of
gem packages that do gem-specific things in such a way that it makes
things difficult for RPA.  We can polish these rough edges away over
time as we move toward 1.0 of both systems.  The ideal scenario is
that any RubyGem can be RPA-ified (pre QA) with a single script.  And
vice versa.

Chad