[DRE-maint] Call for review: new version of "Position on rubygems"

[Gunnar Wolf]

Lucas Nussbaum dijo [Sun, Feb 22, 2009 at 07:18:44PM +0100]:
> Hi,
> 
> I attended a RubyCamp yesterday, which gave a very positive attitude of
> the Ruby community (at least the local one, of course :P).
> 
> I discussed the rubygems issue with them, and I think it basically
> boils down to a lack of information on our side. I've tried to rework
> the "Position on rubygems" page, matching how I explained the issue
> during the RubyCamp.
> 
> I also modified "Dear upstream devs" slightly.
> 
> The content completely changed, so I'd like you to review it before it
> replaces the current one. Please send ACKs if you agree with the
> changes.

Hi,

Thank you for taking the time to do this - I agree, we _need_ to
tackle this issue before Squeeze. Our current integration with the
Ruby scene (and culture) hurts quite a bit.

On your re-writing of the pages: I agree with the general
spirit. However, maybe we should move a bit more, given the evolution
in Rubyland. We have so far requested authors not to package as gems,
and I recognize it as a (good!) sign of acknowledging the reality that
you switch it to "package your Gems, but also provide a
.tar.gz". However... A gem is much like a .deb, in that it is an
archive containing a tarball and metadata (data.tar.gz and
metadata.gz). And although data.tar.gz unpacks on the current
directory, I guess we could save quite a bit of animosity by handling
gems as we handle a regular orig.tar.gz.

Same thing goes regarding setup.rb - Very few Ruby projects ship it
nowadays, and it is largely irrelevant. But we have it packaged in
Debian, and it usually Just Works(tm). Maybe we should encourage not
to use any interesting layouts which break assumptions...

I do see as dirty and unfortunate the «require 'rubygems'» and the
«require_gem» syntaxes. It just... feels dirty. A single 'require'
command should suffice for all uses! And yes, Ruby breaks its own
assumptions by having Gems laid out differently to what it
expects. But still, it is one point instead of many.

Back on the first point: I can see two possible approaches. The first
one would be repacking gems as tarballs (which could be done with a
very simple script), but we would lose the pristine source. On the
other hand, we could fiddle around with dpkg (I have to confess I am
completely unfamiliar with the dpkgv3 format, so I am only assuming
this is possible as AFAIR it solves the tarball-in-a-tarball
situation) to accept gems as orig.tar.gz. 

Greetings,

-- 
Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF