Ruby packaging in wheezy: gem2deb, new policy, etc.

[Lucas Nussbaum <lucas@lucas-nussbaum.net>]

Hi,

After quite some work together with Antonio Terceiro, we now have a mostly
working gem2deb implementation. It can handle everything needed to package
ruby applications and libraries inside Debian, and is much better than the
current cdbs-based tool:
 - does almost everything automatically
 - uses dh7, much faster
 - easier to adapt to our needs
 - runs the test suite as part of the build

The source is available from https://github.com/ln/gem2deb
To test, you need to:
git clone git://github.com/ln/gem2deb.git
cd gem2deb
rake install
then, cd to some temporary place, and do:
gem fetch rdiscount # a native gem
gem2deb rdiscount<TAB>
or:
gem fetch i18n # a pure ruby gem
gem2deb i18n<TAB>

This tool has two goals:
- serve as a way for users to generate debs from gems locally
- serve as a basis for packages provided in Debian

However, there are several questions that need to be answered:

1) Do you want to move to that tool for Ruby packaging in Debian?
(I'm assuming we do)

2) How should the packages be named? Since all the packages are going
to be modified anyway, it's the perfect time to change the naming.
 I'd like to go with:
 + ruby-foo for pure ruby libs
 + ruby1.8-foo, ruby1.9.1-foo, and ruby-foo (common files) for native libs
This is what python uses, and is much nicer than the current perl-inspired
naming.
 
3) Should we change our packaging workflow? Using gem2deb, it would be quite
easy to use git-buildpackage with:
- an upstream branch
- a gem2deb branch, providing the source package as generated by gem2deb
- a debian branch, with the source package based on the gem2deb branch
I believe that in most cases, we will only need marginal modifications
from the gem2deb generated package, so this would be a good way to have
an efficient workflow.

4) How should we migrate to the new packages? If we want to enable test suites
during build (which would be a good thing), we need to be extremely careful
about dependencies. Using the dependency info from the rubygems spec files,
which is very far from being complete, I got the following graph when looking
at the deps for the top 10 gems: http://blop.info/pub/rubydeps.pdf
We could do a two-steps migration, first uploading the packages with the test
suite disabled (so they can build fine) and then re-upload to enable the test
suite when all the deps for it are available.

- Lucas