This page describes the various changes to Ruby packaging that are planned for Wheezy.
Contents
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.
The guidelines are the following:
pure-ruby libs must produce a single binary package named ruby-foo
native libs must produce a binary package named ruby-foo, plus one binary package for each supported interpreter: ruby1.8-foo, ruby1.9.1-foo, etc.
Handling dependencies between Ruby binary packages
pure-native packages: ruby-foo must 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 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.
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.8.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. 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 request the removal of the old package.
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?
- Update ruby1.8, ruby1.9.1 and rubygems:
- Update to their latest versions
- Make changes outlined above (rubygems changes, switch to alternatives)
- Upload gem2deb to Debian
- Make the necessary changes to pkg-ruby-extras infrastructure (prepare git repo)
- 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)