Differences between revisions 2 and 3
Revision 2 as of 2011-01-26 08:19:03
Size: 5183
Comment:
Revision 3 as of 2011-01-31 00:55:16
Size: 5624
Comment:
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
===== Switch to 1.9 as default ===== Each ruby implementation will provide '''ruby-interpreter'''. Pure-ruby packages must depend on '''ruby-interpreter'''.

=== Switch to 1.9 as default ===
Line 16: Line 19:
==== Handling of dependencies ====
Each ruby implementation will provide '''ruby-interpreter'''. Pure-ruby packages will depend on '''ruby-interpreter'''.
For inter-third-party-software dependencies:
 * pure-ruby libs are named '''ruby-foo'''.
 * native libs are named '''ruby1.8-foo''', '''ruby1.9.1-foo''', etc. and provide '''ruby-foo'''
 * libraries depend on '''ruby-foo'''
 * 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.8.1-foo (>1.0) || ...'''
== Package other interpreters ==
Line 24: Line 21:
==== 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

==== Package other interpreters ====
Line 35: Line 26:

=== Naming of ruby packages ===

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, it is the perfect time to do that.

=== Handling dependencies between Ruby packages ===

 * pure-ruby libs are named '''ruby-foo'''.
 * native libs are named '''ruby1.8-foo''', '''ruby1.9.1-foo''', etc. A dummy package called'''ruby-foo''' will depend on '''rubyXXX-foo''', where '''XXX''' is the default ruby version (currently 1.8, but 1.9.1 in the future)
 * libraries with both pure-Ruby and native code must be handled like this:
 ** '''ruby-foo''' contains the pure-Ruby code, and depends on '''rubyXXX-fooo''' (where '''XXX''' = default ruby version)
 ** '''ruby1.8-foo''', '''ruby1.9.1-foo''' contain the native libraries, and depend '''ruby-foo''' (yes, there is a circular dependency)
 * libraries depend on '''ruby-foo'''
 * 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.8.1-foo (>1.0) || ...'''

=== 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
Line 66: Line 77:
=== Naming of ruby packages ===
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, it is the perfect time to do that.

This page describes the various changes to Ruby packaging that are planned for Wheezy.

Planned changes

Changes to interpreter packaging

Use alternatives to switch between Ruby implementations

There is a huge demand (see #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. But that decision can probably wait.

Package other interpreters

It would be nice to make progress towards having the same support for Rubinius and JRuby.

  • For JRuby, it is available in Debian, for is 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 #591817)

Changes to third-party libraries and software packaging

Naming of ruby packages

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, it is the perfect time to do that.

Handling dependencies between Ruby packages

  • pure-ruby libs are named ruby-foo.

  • native libs are named ruby1.8-foo, ruby1.9.1-foo, etc. A dummy package calledruby-foo will depend on rubyXXX-foo, where XXX is the default ruby version (currently 1.8, but 1.9.1 in the future)

  • libraries with both pure-Ruby and native code must be handled like this:
  • * ruby-foo contains the pure-Ruby code, and depends on rubyXXX-fooo (where XXX = default ruby version)

  • * ruby1.8-foo, ruby1.9.1-foo contain the native libraries, and depend ruby-foo (yes, there is a circular dependency)

  • libraries depend on ruby-foo

  • 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.8.1-foo (>1.0) || ...

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

gem2deb is a replacement for our current cdbs-based packaging suite. It:

  • does almost everything automatically
  • uses dh7 (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:
gem fetch rdiscount # a native gem
gem2deb rdiscount<TAB>
or:
gem fetch i18n # a pure ruby gem
gem2deb i18n<TAB>

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 the naming of packages (see below)
  • 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

Is it worth it? Some people like to use ri, and having a local copy of rdocs is sometimes helpful, even if there are services like rdoc.info.

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

How do we proceed?

  1. Update ruby1.8, ruby1.9.1 and rubygems:
    • Update to their latest versions
    • Make changes outlined above (rubygems changes, switch to alternatives)
  2. Upload gem2deb to Debian
  3. Make the necessary changes to pkg-ruby-extras infrastructure (prepare git repo)
  4. package or repackage software with gem2deb
    • Start with "core" software: required by other libraries to build, etc. good targets are stuff involved in test suites.

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 ;-) (j/k.that's not really an achievable goal)