[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

How to handle libraries bundled with either Ruby 1.8 or Ruby 1.9 (was "Debian Ruby packaging changes")

Hello all,

I wish to raise a discussion on this point.

Francesco and Thomas, sorry if it goes way beyond your goals, but you
raised a point that the Ruby team probably needs to reach a consensus

All, please make sure you keep debian-ruby@l.d.o copied.

Francesco Poli escreveu isso aí:
> On Mon, 20 Jun 2011 07:48:08 +0200 Lucas Nussbaum wrote:
> [...]
> > Quick review of your package:
> > 
> > - is there a reason not to package https://rubygems.org/gems/soap4r ?
> > Ok, it might not work with 1.9, but maybe you could backport the changes
> > from soap4r-ruby1.9 ?
> [...]
> > Also, we really want to support both 1.8 and 1.9, not just 1.9.
> Please forgive my ignorance: AFAICT the soap library is integrated in
> libruby1.8, hence what's the use of having a separate soap4r package
> that works with Ruby 1.8 ?
> $ dpkg -S /usr/lib/ruby/1.8/soap/rpc/driver.rb 
> libruby1.8: /usr/lib/ruby/1.8/soap/rpc/driver.rb

In fact, it is included in ruby1.8.

That's a question that has been popping up now and then, and probably we
need to reach a consensus on the Ruby team.

1) There is a lot of cases in which libraries were bundled together with
Ruby 1.8, and were dropped in Ruby 1.9. Examples:

  * test-unit: Ruby 1.9 dropped test-unit, and added minitest. minitest
    has some compatibility with test-unit, but it does not implement
    everything. This way some people are maintaining it as a separate
    package: http://rubygems.org/gems/test-unit
  * soap4r: Ruby 1.9 dropped it, and it is now being maintained as a
    separate package: https://rubygems.org/gems/soap4r
    But it seems that not even this is compatible with Ruby 1.9, so
    there are forks claiming this support.

2) Another case is software that was not bundled with Ruby 1.8, but was
bundled with Ruby 1.9. Examples:

  * rubygems
  * rake


I see to ways to go with this:

a) Always let the bundled version take priority. For example, with Ruby
1.8 has a bundled version of foo, then the ruby-foo package only
installs files for Ruby 1.9 (and vice versa).

  * Pro: bundled library behaves as it does in upstream Ruby
  * Con: bundled does not evolve much

b) Always make the non-bundled version have priority over any bundled
versions. This way we would make for example the ruby-soap4r package be
used for both Ruby versions, even though there is a bundled version for
Ruby 1.8.

  * Pro: library works consistently across Ruby versions.
  * Con: non-bundled version (potentially) behaves different than
    bundled version.


We have been handling case 2) with solution a). Both rubygems and rake
install files only for Ruby 1.8.

AFAICT we are starting to handle case 1) now.

AFAICT the Ruby community at large uses solution b). For example, if
some package depends on rake, rubygems will just install it and the
rubygems-installed version will take over the bundled version. Even
Rubygems itself can be installed from source on Ruby 1.9 and take over
the bundled version (and my guess is that people do that).

Antonio Terceiro <terceiro@softwarelivre.org>

Attachment: signature.asc
Description: Digital signature

Reply to: