On 21/06/11 at 23:32 +0200, Thomas Müller wrote: > > > 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 [email protected] 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?
It's not really maintained, it's just part of the ruby1.8 source package. > 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. I agree. > Shall we maintain a Debian fork? > > I think best would just be to get upstream back in action. > Let me ask the two guys ... Yes... Maybe that's something else to raise on ruby-core@ ? :) - Lucas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
