Hi!
In a few weeks from now, 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.
You receive this email because you are listed as the maintainer or
uploader of a Ruby package which has been detected as not using this new
policy. See the list of maintainers/packages at the end of this email.
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 the overall quality of Ruby packages in Debian
and to ensure consistency in the way Ruby packages are installed and
used, we need to finish the transition, and therefore we strongly
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], most of which being taken care of automatically by
our packaging tool gem2deb.
1:
http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/ruby-policy.git;=summary
2: http://packages.debian.org/sid/gem2deb
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 [3].
3: 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 [4] of the
team.
4:
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 you to update these Ruby packages
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
