Dear Release Team, Since the beginning of the development cycle for Wheezy [0], the Ruby team has been working on several big changes in the Ruby policy for a better support of several versions of the interpreter and improvement of the global quality of Ruby packages.
0: http://www.lucas-nussbaum.net/blog/?p=681
The packaging rules are described on a dedicated Wiki page [1] and in a
draft of the Ruby policy [2].
1: http://wiki.debian.org/Teams/Ruby/Packaging
2:
http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/ruby-policy.git;=summary
The Ruby team has been putting a lot of effort [3] during this
development cycle to convert the packages they maintain to this new
policy (270+ packages).
3: http://pkg-ruby-extras.alioth.debian.org/wheezy/
Unfortunately, many packages not maintained by the team still follow the
now obsolete policy used for Squeeze. It is vital that the transition
finishes before the release of Wheezy, in order to ensure coherence in
the installation and use of the Ruby libraries and applications in the
stable release. In order to talk the maintainers of these packages into
converting them to the new policy, we want to send an email to
debian-devel-announce@l.d.o with the content below.
However, in case the transition is not completely finished for the
freeze, could you suggest ways in which the team can act? Is it
conceivable to add the end of the Ruby transition as a release goal?
Would it be OK to consider Ruby packages that have not transitioned as
NMU-able in order to make them comply to the new policy? On the other
hand, transitioning a packaging is quite invasive (e.g. most of the time it
includes renaming both source and binary packages), so perhaps you may
have other suggestions.
Thank you very much,
For the Ruby Team,
Cédric Boutillier
******************************************************
Proposition for the message to debian-devel-announce@:
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 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. If you maintain Ruby packages, please read until the end ;).
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 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-r...@lists.debian.org or on the #debian-ruby IRC
channel.
signature.asc
Description: Digital signature
