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

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



Lucas Nussbaum escreveu isso aí:
> > 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.

What about 2), e.g. rake and rubygems? Do you think we could always
default to the non-bundled version for them as well?

-- 
Antonio Terceiro <terceiro@softwarelivre.org>
http://softwarelivre.org/terceiro


Attachment: signature.asc
Description: Digital signature


Reply to: