Re: How to handle libraries bundled with either Ruby 1.8 or Ruby 1.9 (was "Debian Ruby packaging changes")
Am Dienstag, den 21.06.2011 um 7:05 schrieb Lucas Nussbaum:
> 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
>
All this just started because nobody is maintaining upstream.
Who is maintaining soap4r for ruby 1.8 within the Debian community?
What is the {svn|git|*}-location?
Shall we add the 1.9 branch to that repo?
To tell the truth - I'm not happy with the current ruby1.9 source from where I did grep it.
>From a developer point of view github is awesome: clone a repo and do your own fork.
>From a maintainer point of view it's just a pure nightmare to e.g. find out who did change what and why.....
The copyright is painful as well, because you don't get the real names and/or not the email addresses.
Shall we maintain a Debian fork?
I think best would just be to get upstream back in action.
Let me ask the two guys ...
Cheers,
Thomas
>
> --
> To UNSUBSCRIBE, email to debian-ruby-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: 20110621050501.GA6669@xanadu.blop.info">http://lists.debian.org/20110621050501.GA6669@xanadu.blop.info
Reply to: