[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
SVN: svn://svn.debian.org/pkg-ruby-extras/tools/ruby-support/trunk
or http://svn.debian.org/viewsvn/pkg-ruby-extras/tools/ruby-support/trunk

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.

New rules:
[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
      ruby1.8  /usr/lib/ruby/vendor_ruby/1.8 
      ruby1.9.0  /usr/lib/ruby/vendor_ruby/1.9.0 
      ruby1.9.1  /usr/lib/ruby/vendor_ruby/1.9.1 
    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
       Ruby version.
       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
    be avoided.

[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
is provided.

| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Reply to: