[ 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@ ]
Hi, 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 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 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. Comments? -- | Lucas Nussbaum | [email protected] http://www.lucas-nussbaum.net/ | | jabber: [email protected] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
