Hi! In about two months, Wheezy will be frozen. One of the goals of the Ruby Team for Wheezy is to try to push as far as possible the transition to a new policy for Ruby library. The Debian Ruby Team have put a lot of effort on this goal, converting (most of) the packages they maintain to this policy. The success of this effort can be measured on the graph [0]. 0: http://pkg-ruby-extras.alioth.debian.org/wheezy/ The data used for this graph taken into account *all* Ruby libraries contained in Debian, and not only those maintained by the Ruby packaging team. In order to improve these statitistics and finish the transition, we would like to encourage all maintainers of Ruby packages in Debian to update their packages to reflect these changes. These changes concern three different aspects: the package naming convention, the path where libraries are installed, and the execution of test suites at build time. These aspects are briefly described below and detailed in the draft of the Ruby policy [1]. If you maintain Ruby packages, please read until the end ;). 1: http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/ruby-policy.git;a=summary Naming conventions ------------------ The source packages libfoo-ruby should be renamed ruby-foo. If these packages provide extensions needing to be compiled for the various Ruby versions, these should nevertheless be shipped in the same binary package, also called ruby-foo. If the package is mainly used as an application, then it can be named just "foo". The naming convention can be of course adapted in the case of the packaging of utilities (chef, rails, redmine...). With the convention we used before, not only were we shipping distinct Ruby packages per interpreter version (i.e. libfoo-ruby1.8 and libfoo-ruby1.9.1) and needed to hold large-scale repackaging on ABI jumpis (as in the latest 1.9 → 1.9.1 change). With this new convention (and build system – read on for details) only one binary package will be built, and will carry all of the needed components, either in a common place or in the version-specific directories. For more extensive information see our guidelines for Ruby packaging [2]. 2: http://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging Install locations for libraries ------------------------------- Libraries not bundled with the Ruby interpreters should be installed somewhere in /usr/lib/ruby/vendor_ruby directory, instead of /usr/lib/ruby/1.8 or /usr/lib/ruby/1.9.1. A Pure Ruby library working for all Ruby version would go in /usr/lib/ruby/vendor_ruby. Files specific to a version of the interpreter should go in /usr/lib/ruby/vendor_ruby/$RUBYVER (vendorlibdir). Code compiled specifically for the host architecture should go to /usr/lib/ruby/vendor_ruby/$RUBYVER/$ARCH (vendorarchdir) For the moment, MRI Ruby 1.8 and 1.9 can use the libraries installed in these directories. JRuby would need to have theses directories added to $LOAD_PATH and advertised by RbConfig (see #663342). Running test suites during package build ---------------------------------------- A large number of Ruby libraries provide a test suite. It is recommended to run these tests during the construction of the package in order to check that the package will (at least partially) work with the interpreters and other libraries included in the distribution. A new packaging tool: gem2deb ----------------------------- The "gem2deb" tool takes care of most of the points mentioned above in an automatised way. Running gem2deb on your orig tarball or a gem package from your upstream will get you most of the way towards making your package compatible with the new draft Ruby policy. Instructions for the transition to gem2deb are available on the wiki page [3] of the team. 3: http://wiki.debian.org/Teams/Ruby/Packaging#Howto:_converting_a_package_from_ruby-pkg-tools_to_gem2deb gem2deb builds binary packages which are amenable to all of the currently existing Ruby interpreters, and is future-proofed so that when a new one is included in Debian, all of our packages will gain support with just a rebuild. It also adds niceties such as proper Gem following via debian/watch or packaging with simple, current practices for debian/*. Please do consider repackaging using it! To conclude, we encourage Ruby Library maintainers to update their packages so that they follow the guidelines above. Everyone willing to team maintain their Ruby packages is of course welcome to join the Ruby Packaging team (pkg-ruby-extras on alioth) and import their packages in the team repository. We would be happy to answer your questions and hear your comments on debian-ruby@lists.debian.org or on the #debian-ruby IRC channel.