Re: Candidate new Ruby policy, version 2
Hi,
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
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
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
supported.
[B] Ruby libraries must be installed in "vendor" directories, not mixed
with the ruby standard library. For Ruby1.8 and 1.9, that means
using:
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"
scheme).
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)
TODO:
- 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: