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

Re: Candidate new Ruby policy, version 2


This is an update of the new ruby policy, which tries to address the
various comments that were made. Main changes:
- Keep the libxxx-ruby(|xxx) naming scheme. This should make the
  transition slightly easier.
- Add a section about dependencies.
Please review and comment!

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

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

New rules:
[A] Ruby libraries must support (be usable with) as many as possible of the
    Ruby versions available in Debian. That currently includes Ruby 1.8,
    Ruby 1.9.0 and JRuby 1.1. Ruby 1.9.1 and JRuby 1.2 will be uploaded
    soon, and will replace Ruby 1.9.0 and JRuby 1.1.
    It means that not supporting Ruby1.9.1, or JRuby, must be considered
    a bug by the maintainer. Since we are likely to move to Ruby1.9.1
    for the default version of Ruby in the future, not supporting
    Ruby1.9.1 should be considered an important bug.
    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 libxxx-ruby 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.)
       This libxxx-ruby package Replaces, Provides the superseded
       libxxx-ruby1.X packages.

    several libxxx-ruby1.9.0, libxxx-ruby1.9.1, libxxx-jruby1.1, etc.
    as well as a libxxx-ruby pkg which is a simple dependency package:
       Several packages, each one containing support for a specific
       Ruby version.
       And one libxxxx-ruby 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 "only one libxxx-ruby package"
       This is the recommended way to support native libraries, as it
       avoids adding a dependency on each available Ruby version.
       Note that existing libxxx-ruby1.9 packages must be replaced
       by lib-ruby1.9.(0|1) packages.

    Other packages can of course be provided, and named
    libxxx-ruby-(doc|examples), but packages proliferation should
    be avoided. It is a better idea to use the "main" libxxx-ruby
    package to provide documentation, unless the documentation is huge.

[D] Ruby library source package naming policy. If there isn't an obvious
    better choice, new source packages should be named libxxx-ruby,
     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
    libxxx-ruby naming) or keep their existing name.

[E] Dependencies between Ruby packages:
    Applications that use the Ruby interpreter and ruby libraries:
       MUST choose (and be tested) with a specific Ruby version, and
       depend on the exact ruby version.
       MUST depend on libruby1.X for that version of Ruby.
       SHOULD NOT depend on ruby1.X directly, unless it needs the
       interpreter binary.
       MUST NOT depend on 'ruby'.
    Pure-ruby libraries (one libxxx-ruby package):
       MUST depend on libruby | ruby-interpreter (will be provided by the
       various interpreters)
       MUST depend on the other ruby libraries that are being used. When
       those other libs are native libs, use libxxx-ruby1.8 |
       libxxx-ruby1.9 | libxxx-jruby1.2 | ... to avoid forcing the user
       to install all ruby versions.
       MUST depend on ruby-support if they use it.
     Native ruby libraries (several libxxx-rubyXXX packages):
       Each package depends on its own version of Ruby (by depending
       on librubyXXX)

- Get Ruby 1.9.1 and JRuby 1.2 ready:
  + fix the ruby1.9.1 wrong vendor dir bug 
  + use the -ruby1.9.1 suffix instead of -ruby1.9
  + add a vendor dir to jruby
  + upload jruby1.2
  + add Provides: ruby-interpreter to the various implems
- Develop scripts to track the transition status.
- Upload ruby-support when the support for pure-ruby libs is finished
  (we are almost there)
- Migrate all pure-ruby libraries to the new scheme
- Fix reverse dependencies
- Determine whether we want to provide something in ruby-support for
  native libs. Implement it.
- Migrate all native libraries to the new scheme
- Fix reverse dependencies
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Reply to: