[Rubygems-developers] Adoption

Mauricio Fernández batsman.geo at yahoo.com
Thu Oct 21 12:13:09 EDT 2004

On Thu, Oct 21, 2004 at 11:17:26AM -0400, chad at chadfowler.com wrote:
> >> If you want to see what people are asking for, as far as packages are
> >> concerned, you can take a look at
> >>  http://rpa-base.rubyforge.org/wiki/wiki.cgi?Package_Requests
> >> and the list of libs/apps I've packaged so far:
> >>  http://rpa-base.rubyforge.org/wiki/wiki.cgi?Packaged_Software
> >> (many were packaged on demand).
> >
> > This seems to be a useful start. Thanks.
> >
> >> It would be very nice if you could package Ruby DBI: that's something
> >> many other libraries depend on and it is used fairly often. It seems
> >> non-trivial, though.
> >
> > I've added it to the list and will give it a shot. Thanks.
> >
> Another good list is the delta between packages in RPA and RubyGems. 
> There are quite a few differences in the package lists.  In some cases
> (though certainly not all) the effort and lessons learned from having
> packaged something in RPA could make it easier to do the gems.
> Perhaps Mauricio could provide a list of guidelines (in addition to what's
> on the wiki) that would also make these new gem packages easier to
> RPA-ify.

For the time being, it is preferable to repackage directly the original
sources (tarball or equivalent, especially when using setup.rb) instead
of the Gem, so Marcel's work would not be very useful for 3rd party
repackagers and for RPA in particular.

However, you have to keep in mind that the 'gemification' process can
involve more than just creating a .gemspec: it could need a Rakefile
and/or patches to the sources (such as adding  require 'rubygems').
If non-trivial RubyGems-specific patches (and even some trivial ones :)
are merged upstream, the original sw. could become harder to repackage for
RPA as well as for other repackagers. 

I know you care about RubyGems being easy to repackage; the simplest way
I can think of, given the current implementation, would be maintaining
a separate "RubyGems patch", so that the pristine, packager-neutral
sources remain available.

In other words, in the current situation it's not as much about making it
easier as about *not* making it harder to repackage, because RubyGems
aims at being the canonical system and being integrated into the upstream
releases, replacing other mechanisms like Aoki's setup.rb.

That said, if RubyGems normalized the directory structures, numbering
schemes, etc of the upstream sources, it *could* become the input format
of choice for repackagers...

Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

More information about the Rubygems-developers mailing list