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 - gw...@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 _______________________________________________ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-ruby-extras-maintainers