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 | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
