Steffem Joeris wrote: > On Wed, 8 Apr 2009 05:10:12 pm Romain Beauxis wrote: > > Le Tuesday 07 April 2009 22:59:00 Sebastien Delafond, vous avez écrit : > > > On Apr/07, Mike Hommey wrote: > > > > While I see why it can be needed for python, I fail to see how it is > > > > important for jruby... > > > > > > to have 2 versions of jruby available ? I guess so you can at least, for > > > instance, try the new one on your existing jruby code without removing > > > the old one, for instance ? > > > > If we were to apply this policy to all software packaged in debian, that > > would be a mess. > It would be a security mess as well, I don't particularly want to fix the same > issue in 2-4 packages ... > > > > Are you advocating for only one instance of jruby at all times in the > > > archive ? If so, why ? > > > > I think this is the other way round: by default there should be only one > > version per package -- after all that is why we have package name and > > package version.. > > > > Hence, it should be explained why multiple version of the same package are > > relevant for Debian and its users. And I don't think that "testing several > > versions" is a good explanation.. > If a dozen (or more) packages really need the older version, then it could be > discussed I guess (some details here would be nice). But I agree that having > it around for "testing" reasons is not a valid reason. JRuby 1.0, 1.1, and 1.2 are not different mutually incompatible versions of the language. All are attempts to do an increasingly better (and faster) job of implementing both the Ruby 1.8 and Ruby 1.9 langugages, and therefore version 1.2 ostensibly replaces version 1.1 by being better than it. If there are packages that are broken under JRuby 1.2, they should be fixed. JRuby 1.2 should be packaged simply as "jruby", and all of the others should be removed from the archive immediately when that happens. If there are version-numbered library paths (i.e. /usr/lib/jruby1.1) to be concerned about, you should remove the version-number from those paths. If subsequent versions of JRuby introduce incompatible API changes, then you should work out a library transition to the new number each time a new version of JRuby is packaged that changes the library path. Furthermore, nothing in the archive currently depends on jruby1.0 or jruby1.1, so there's nothing to transition, and nothing you're breaking by fixing this now. --Ken
Attachment:
signature.asc
Description: This is a digitally signed message part