Hi all,
I've been in the (much delayed) process of writing up packaging
guidelines [1] for Fedora, and they have been discussed with the Fedora
Packaging Committee, which needs to approve them before we can create
RPM packages from gems. There's a few things I'd like to get input from
people who understand gems way better than I do. Apologies in advance
for a somewhat lengthy post.
The goal of this is to wrap Ruby gems as easily as possible in RPM's so
that Fedora users can install them using their RPM-based tools (like
yum), have them show up in the RPM database etc. At the same time, I
want to avoid breaking any expectations Ruby developers have how gems
work, e.g. 'gem list --local' should still work, RPM-packaged gems
should be fully recognized by gem, so that if I install a gem 'foo' from
an RPM, I can still use gem to install a gem 'bar' that depends on 'foo'
and have the RPM-installed one satsify that dependency.
Here then is a random list of issues I'd like to get some guidance on:
Multilib
========
Ruby Gems doesn't have any provisions for multilib systems, i.e.,
systems that can run both 32-bit and 64-bit code. Multilib in general is
a thorny issue, and the goal is to enable users to have 32-bit and
64-bit versions of libraries installed simultaneously. In the guidelines
draft I wrote that arch specific code (e.g., DSO's) need to be moved
from the gemdir into Config::CONFIG["sitearchdir"], the dirs set up by
the ruby RPM for this purpose.
Would it be possible for gems to support that natively, e.g., by
sticking dirs like i386-linux and x86_64-linux into the lib/ dirs of a
gem and installing arch specific content there ?
Lack of LSB compliance
======================
Debian states [2] that Gems aren't LSB compliant (and that is
unfortunately echoed on the rubygems website, though I couldn't find the
reference just now) I think it's a bit of an overstatement; the only LSB
violation with Gems that I can think of is that executables might wind
up in /usr/lib, since Gems might contain commands in a bin/ directory.
Really only a problem if files in those bin/ directories are actually
arch-specific and not just ruby scripts. Is there any way to remedy
that, e.g. by putting such commands into /usr/bin ?
For real LSB purists, there are probably some other things they won't
like about Gems, e.g. that documentation goes into the gem dir instead
of /usr/share/doc, though I think that can be discussed away; fixing it
would require a lot more configurability in Gems, and I doubt it's worth
the effort.
Gem and non-Gem versions of the same library
============================================
Since using a gem in your code requires that you do something like
require 'rubygems'
require 'mygem'
there's a chance that people need the same library installed as a Gem
and as a non-Gem. For Fedora, we'd very much like to avoid that there
are two different packages with almost the same bits that install into
two different locations to support this.
I'm experimenting with putting symlinks to things in the gem dir into
the standard ruby library path - I was wondering if there are any plans
to support that with gems more directly.
Generating RPM specfiles
========================
Since Gems carry almost all the information that is needed to build an
RPM, I've hacked up a little script to generate a RPM specfile from a
ruby gem [3]; this is only meant to help people write the initial RPM
spec, after that they have to maintain it manually. I was wondering what
you think of adding such a tool to rubygems directly (I think the PHP
pear people do that, and it's generally liked a lot)
For examples of what RPM specfiles look like for Rails, have a look at
[4]
David
[1] http://fedoraproject.org/wiki/PackagingDrafts/RubyGems
[2] http://pkg-ruby-extras.alioth.debian.org/rubygems.html
[3] http://people.redhat.com/dlutter/gem2spec.html
[4] http://people.redhat.com/dlutter/yum/spec/
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
