Candidate new Ruby policy
[ In addition to debian-ruby@, this mail was sent to several individuals
or lists. If you are not subscribed to debian-ruby@, and receiving this
mail, please subscribe to it. Also, M-F-T set to debian-ruby@ ]
This is a candidate summary of a new ruby policy. It doesn't cover all
the details, but try to include all the recent (proposed) changes in
Ruby packaging. This aims at solving several problems, including the
better support of Ruby 1.9.1 and JRuby (and automatic support, for
libraries, for future new versions of Ruby and JRuby).
Note that the ruby-support package mentioned later has not been uploaded
to unstable. Don't hesitate to contact me if you want to help working on
it. Help is badly needed, for testing, and improving CDBS support.
Please reply to this mail, even if it's just to say "I'm OK with that".
I would like to avoid moving further will all this without having broad
agreement that this is the way to go.
[A] Ruby libraries must support as many as possible of the Ruby versions
available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0
(soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?)
ruby-support --supported lists the versions that should be
[B] Ruby libraries must be installed in "vendor" directories, not mixed
with the ruby standard library. For Ruby1.8 and 1.9, that means
For JRuby, a change is needed to create such a directory. No
"vendor" dir is supported currently.
ruby-support --supported lists the directories where libraries
must be installed.
[C] Ruby library package naming policy. Ruby library packages can
choose between two naming schemes:
only one ruby-xxxx binary package:
(mostly for pure-ruby libraries)
the package contains support for all (or most) of the
available ruby version. If it's a pure-ruby library, using
ruby-support to generate a symlink farm is recommended (similar
to what is done with python-support, i.e symlinks are installed
for each version of ruby, but there's only one copy of the
library on the filesystem, to save disk space.)
several ruby1.9.0-xxxx, ruby1.9.1-xxxx, jruby1.1-xxxx, as well as
a ruby-xxxx which is a simple dependency package:
Several packages, each one containing support for a specific
And one ruby-xxxx binary package that will be (mostly) empty,
and only depend on the current default ruby version.
This should not be used for pure-ruby libraries (unless there's a
very good reason not to use the ruby-xxxx scheme).
This is the recommended way to support native libraries, as it
avoids adding a dependency on each available Ruby version.
Other packages can of course be provided, and named
ruby-xxxx-(doc|examples), but packages proliferation should
[D] Ruby library source package naming policy. New source packages
should be named ruby-xxxx, with xxxx being the name of the library.
Of course, there are lots of special cases here, and there might
be better names for the source package name of some libraries.
Existing Ruby libraries can either change name (and adopt the
ruby-xxxx naming) or keep their existing name.
Something that still needs to be properly documented is the content of
the Depends: field of each kind of Ruby package. I will make sure that,
before we have to start migrating packages, a documentation for that
| Lucas Nussbaum
| firstname.lastname@example.org http://www.lucas-nussbaum.net/ |
| jabber: email@example.com GPG: 1024D/023B3F4F |