Re: How to handle libraries bundled with either Ruby 1.8 or Ruby 1.9 (was "Debian Ruby packaging changes")
On 20/06/11 at 12:05 -0700, Antonio Terceiro wrote:
> 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
> on.
>
> 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).
Hi,
I'm in favor of doing (b) for (1). In the most extreme case, it means
dropping the library from the ruby1.8 source package, and (maybe) depend
on the non-bundled version.
In the case of soap4r, we ship a patched version in the ruby1.8 package,
because soap4r shipped in ruby1.8 is unmaintained upstream.
It would be better to switch to a maintained upstream version instead.
- Lucas
Reply to: