[Pkg-ruby-extras-maintainers] Debian/Ruby and RubyGems

[Paul van Tilburg]

Hi Branden,

I am mailing on behalf of the Debian/Ruby Extras team.  Note that this
team indeed is new and still growing.  The team concerns itself only
with libraries and applications that not belong to the Ruby core stuff
(standard library, interpreter etc.).  That part is still in the hands
of our crafted Japanese developers.

It seems that because of the past split-up of the Ruby core packages[0],
Debian has fallen in discredit within the growing Ruby community.  We
have worked hard to get it all fixed for sarge, but now a new issue has
come up: RubyGems.  All seems to collapse again, we are taking "heavy
fire".

RubyGems[1] is a system for creating and distributing Ruby upstream
packages.  However it does not seem to work well with other
distributions[2] such as ours because of two (maybe more) critical
design decisions they seem to be willing to revise:

* A gem consists of one dir and is installed as such.  This means that
  installing a gem would install some files in /var/lib/rubygems/<gem>
  and this can be any (combination of) binary libs, arch-indep Ruby libs,
  scripts/binary apps, data files and this will violate the FHS.

* The packaging requires changes in upstream source[3]. The require_gem
  adds the gem dir to the load path of Ruby so it can find the library.
  Note that there is no mapping between the gem name and the library,
  we can not write some stub solving this.

Now, RubyGems is about to be moved to CVS HEAD of Ruby and becoming
mainstream.  We have uttered some criticism, but it seems there is no
willingness to listen[4].  (You must know that this Austin Ziegler guy
seems to have had bad Debian experiences and one must see through all
his FUD.)

I've summed some of the issues up on our Wiki:
http://pkg-ruby-extras.alioth.debian.org/cgi-bin/wiki/index.cgi?RubyGems
Generally, this is the same as having CPAN, PHP-pear in Debian, except
that this is much more high-profile.  Having both RubyGems and Debian
lib pkgs will inadvertedly lead to a mess, but can we remove this choice
for our users?  Can and should we bypass the whole system?  Should we go
with IMO unclean solutions as converting a gem to a deb[5] or shipping a
binary gem within a binary deb and install/remove it in the
post-install/pre-rm scripts as suggested? 

Why mail you?  Well first of all, you have much experience in packaging,
also have you been a part of the project a long time and may know
similar problems.  Secondly we hope that you can give us some advice or
refer us to other developers struggling or have struggled with this.

Thanks for your time,
Regards,

Paul

0: http://lists.debian.org/debian-ruby/2004/08/msg00002.html
1: http://docs.rubygems.org/read/chapter/1
2: http://docs.rubygems.org/read/chapter/14#page62
3: http://lists.debian.org/debian-ruby/2005/02/msg00009.html
4: http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-core/5853
5: http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-core/5958

-- 
Student @ Eindhoven                         | email: paulvt at debian.org
University of Technology, The Netherlands   | JID: paul at luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20050925/b04e4d84/attachment.pgp