On Wed, 6 Oct 2004 22:48:07 +0900, Chad Fowler <chadfowler / gmail.com> wrote:
> 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 was imprecise here; what I meant was a .tar.gz + standard setup.rb.  

And I'm surprised that you are surprised; I've been hearing grumbling
from various packagers, not just RPA.  This is one of the things that
has been having me frustrated.

> 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 see operating system specific packaging as extremely important, too.
 There are a lot of people that just won't use Ruby programs if they
cannot be installed through the native operating system packages - and
there are a lot of packaging gruops that will not accept a
single-directory solution a la RubyGems.  This may actually be most
groups - it is at least most groups that I know about.

I'm not sure if we need changes to the Ruby base or not - but
attempting to do the package conversion tools should help us find out.
 RPA are working on exports to different packaging formats (we've got
RPM, and are working on.deb and FreeBSD ports at the moment - or
bitserf and Mauricio is, with feedback, help and adoptions from the
rest of us).

> 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.

And converted to other packaging systems, including respecting their
policies.  I believe this is a very important goal - something that
may be significant enough to make or break Ruby as a platform (though
I'm not sure if it is or isn't.)

If we can make this possible, it would be great - I think it could
help raise adoption of Ruby a lot.  Conversely, if we make this
harder, we lower the adoption.

This is sort of orthogonal to the use of the "native Ruby" packaging
systems themselves.

Eivind.