On Fri, Mar 04, 2011 at 09:59:47AM +0100, Lucas Nussbaum wrote:
> Our plans are described on
> http://wiki.debian.org/Teams/Ruby/RubyInWheezy
Text version attached to this mail, for offline reading, quoting, etc.
(It has chances to increase the feedback you can get via -devel ...)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
This page describes the various changes to Ruby packaging that are planned for Wheezy.
<<TableOfContents>>
= Planned changes =
== Changes to interpreter packaging ==
=== Use alternatives to switch between Ruby implementations ===
There is a huge demand (see [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548917|#548917]]) for using alternatives to switch between Ruby implementations. This would provide a way to mimic what RVM provides in a cleaner way, and will help the Ruby community with moving to 1.9.x or other implementations.
Of course, it is clear that some libraries will not work with Ruby 1.9.x or Rubinius or JRuby. The plan is to do something similar to what is done for Java:
* Make sure that everything works with Ruby 1.8 (i.e not working is considered a serious bug)
* Do what we can for other libraries (i.e not working is considered a normal bug), and work with upstream
Each ruby implementation will provide '''ruby-interpreter'''. Pure-ruby packages must depend on '''ruby-interpreter'''.
=== Switch to 1.9 as default ===
Once we use alternatives, it is quite easy to switch to 1.9 as default. However, 1.9 doesn't sound like a reasonable target now, even if it is likely to become one during the wheeze cycle.
== Package other interpreters ==
It would be nice to make progress towards having the same support for Rubinius and JRuby.
* For JRuby, it is in non-free (see [[http://packages.qa.debian.org/j/jruby.html]]) because of some dependencies. We can't depend on it if it stays non-free because it would make all ruby software part of contrib.
* For Rubinius, there's an ITP (see [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591817|#591817]])
== Changes to rubygems packaging ==
* Rubygems should install gems to /usr/local/lib/gems/ (with a proper migration plan)
* Rubygems should install binary wrappers to /usr/local/bin
== Changes to third-party libraries and software packaging ==
=== Naming of ruby packages and dependencies between them ===
The current libfoo-ruby naming, inspired for perl, is not really great. It would be better to move to the python naming, with ruby-foo or ruby1.8-foo. Since all packages will have to be modified anyway to switch to gem2deb (see below), it is the perfect time to do that.
The guidelines are the following:
* pure-ruby libs must produce a single binary package named '''ruby-foo'''
* libraries with both pure-Ruby and native code must be handled like this:
* '''ruby-foo''' is an empty package and depends on '''rubyXXX-foo''' (where '''XXX''' = default ruby version)
* '''ruby1.8-foo''', '''ruby1.9.1-foo''' etc contain the native libraries
* pure-Ruby code must be duplicated in '''ruby1.8-foo''', '''ruby1.9.1-foo''' etc. If pure Ruby code is sufficiently larger than the native one, or if the package also ships other files that are needed by '''ruby1.8-foo''', '''ruby1.9.1-foo''' etc (such as files under /usr/share), then those files must be shipped in a package named '''ruby-foo-common''', and '''ruby1.8-foo''', '''ruby1.9.1-foo''' etc must depend on it.
* '''ruby1.8-foo''', '''ruby1.9.1-foo''' etc must be co-installable.
Inter-libraries dependencies:
* libraries depend on '''ruby-foo'''
* exception: if '''foo''' and '''bar''' are two native libraries and foo depends on bar, then '''rubyXXX-foo''' must depend directly on '''rubyXXX-bar''', and not ruby-bar.
* versioned dependencies are going to be a mess. One solution is to expand the dependency on ruby-foo to '''ruby1.8-foo (> 1.0) || ruby1.9.1-foo (>1.0) || ...'''
=== Renaming existing packages ===
Existing packages must be renamed to the new scheme. This renaming must be done using the standard Debian practices (i.e. [[http://www.debian.org/doc/manuals/developers-reference/pkgs.html#s5.9.3|Debian Developers' Reference, section 5.9.3]]). In our case, this means:
* when '''libfoo-ruby''' gets renamed to '''ruby-foo''', then '''ruby-foo''' must declare '''Provides: libfoo-ruby''', '''Replaces: libfoo-ruby''' and '''Conflicts: libfoo-ruby'''
* when '''libfoo-ruby1.8''' gets renamed to '''ruby1.8-foo''', then '''ruby1.8-foo''' must declare '''Provides: libfoo-ruby1.8''', '''Replaces: libfoo-ruby1.8''', and '''Conflicts: libfoo-ruby1.8'''
* when '''libfoo-ruby1.8''' and '''libfoo-ruby1.9.1''' are turned into a single pure-Ruby package '''ruby-foo''', then it must declare '''Provides: libfoo-ruby, libfoo-ruby1.8, libfoo-ruby1.9.1''', '''Replaces: libfoo-ruby, libfoo-ruby1.8, libfoo-ruby1.9.1''', and '''Conflicts: libfoo-ruby, libfoo-ruby1.8, libfoo-ruby1.9.1'''
* note that this is only needed for packages that were already released with Squeeze. New packages must not keep any references to packages named as lib*-ruby.
* after the renamed package enters the archive, please [[http://www.debian.org/doc/manuals/developers-reference/pkgs.html#removing-pkgs|request the removal of the old package]].
=== Naming of packages ===
Binary packages must normally be named "ruby-foo". If the package is mainly used as an application (not as a library), then it can be named "foo". Known examples are rails, chef, rubygems, puppet.
Source packages must have the same name as the "main" binary package. (our infrastructure is better at handling this case)
=== Handling of shebangs ===
* applications willing to force the use of ruby1.8 should use /usr/bin/ruby1.8 in shebang
* applications willing to use the selected ruby implementation (whatever it is) should use /usr/bin/ruby
=== gem2deb as the preferred packaging tool for ruby software ===
[[https://github.com/ln/gem2deb|gem2deb]] is a replacement for our current cdbs-based packaging suite. It:
* does almost everything automatically
* uses dh (much faster)
* is easier to adapt to our needs, since there's no dependency on an external tool
* runs the test suite as part of the build, for each ruby implementation (yes, it's possible to override this)
* uses one binary package per pure-ruby lib, instead of one binary package per ruby implementation
To test it:
{{{
git clone git://github.com/ln/gem2deb.git
cd gem2deb
rake install
then, cd to some temporary place, and do:
gem2deb rdiscount # native gem
or:
gem2deb i18n # pure-ruby gem
}}}
It serves two goals:
* it can be used by users to generate .debs from gems locally
* it generates Debian source package from which we can do the packaging work
Prerequisites for migrations:
* we need to decide on a workflow for packaging (switch to git?)
* we need to decide on a migration plan to avoid breaking the archive for too long
=== Generation of ri and rdoc documentation ===
We decide not to generate the ri and rdoc documentation, as there are good online services providing it (like rdoc.info).
We might change our mind later. :)
= How do we proceed? =
1. Upload updated interpreter packages, rubygems, and gem2deb to experimental
1. Package a dozen of gems in experimental, make necessary improvements to gem2deb & other packages
1. Finish the discussion on the necessary changes to the pkg-ruby-extras infrastructure (consider switching to git)
= Success metrics =
* There are no binary packages named lib.*-ruby.* in the archive. No package should Depend or Recommend a package named lib.*-ruby.*.
* The only packages installing stuff to /usr/lib/ruby/{1.8,1.9.1} are interpreters. Software packaged with gem2deb will install to /usr/lib/ruby/vendor_ruby/
* Upgrades from squeeze work. ;)
* The Ruby community stops whining about Debian ;-) (just kidding. that's not really an achievable goal)
Attachment:
signature.asc
Description: Digital signature