On Thu, Apr 22, 2010 at 1:37 AM, Lucas Nussbaum
<lucas@lucas-nussbaum.net> wrote:
[ Please continue the discussion on debian-ruby@ ]
Hi,
I'd like to restart a discussion on a set of changes in ruby packaging.
The goals are:
- to find a way to deal with the popularity of rubygems.
- to simplify ruby packaging, so we can keep up with the number of
popular/useful gems
- to be able to support several ruby interpreters at the same time,
preparing the switch to 1.9.X
All those changes are for squeeze+1, but we can start discussing them
now.
I'd like to propose the following actions.
0) We try to provide as much support as possible for all ruby interpreters
(well, at least 1.8 and 1.9.1, but maybe also jruby). However, we decide
on a default version (1.8 currently) that all libraries must support.
1) We base our packaging on rubygems. This doesn't mean that we package gems
directly. But we take upstream gems, convert them to .orig.tar.gz (easy), and
then apply our Debian-specific tools. That allows use to keep the
maximum flexibility of what we can do with the source (patching, etc).
2) Instead of installing to /usr/lib/ruby/1.{8,9.1}, we install to:
/usr/lib/ruby/vendor_ruby/ <= libraries that support all versions
of the interpreter
/usr/lib/ruby/vendor_ruby/1.8 <= libraries that only support 1.8
/usr/lib/ruby/vendor_ruby/1.9.1 <= libraries that only support 1.9.1
That allows to make a better difference between the stdlib and the
third-party libraries.
3) Instead of providing several libfoo-ruby1.{8,9.1} packages, we
provide only one when it is possible (pure ruby packages), named
libfoo-ruby.
When this is not possible (case of packages that contain native extensions),
we continue to provide several binary packages libfoo-ruby1{8,9.1}.
4) When packages provide executable scripts, we either :
- provide them for the various Ruby implementations that we support,
using 1.8, 1.9.1 suffixes. (case for development tools)
- or provide them only for the default version of ruby (case of normal
applications)
5) Regarding test suites, we should really try to execute them during the
build (for every ruby implementation), as this will allow to detect
regressions.
TODO items, provided we agree on the above:
- determine how to deal with Depends, especially in the case of
a pure-ruby library requiring a native extension.
- decide if we want to keep our current cdbs-based packaging system, or
if we want to switch to dh. That would be a nice opportunity.
We might want to really fork setup.rb, too.
- write a set of scripts to package from gems, including:
+ gem2tgz - convert gem to tgz, saving the gem metadata somewhere
+ dh_make_ruby - prepare a source package, making use of the gem metadata
+ script to watch gems on rubygems.org (for debian/watch)
+ various QA scripts, including one to grep for "require 'rubygems'"
Some data:
I've looked at the top 200 gems on rubygems.org.
194 of them provide a lib/ directory, so they probably support setup.rb-based
installation. Of the remaining 6 packages, only 2 don't provide ext/, and
1 has a good reason for that.
55 use "require 'rubygems'" in lib/ somewhere.
112 have a test/ directory, 49 have a spec/ directory.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@lists.debian.org
Archive: [🔎] 20100421200717.GA32010@xanadu.blop.info" target="_blank">http://lists.debian.org/[🔎] 20100421200717.GA32010@xanadu.blop.info