On Wed, Jan 15, 2014 at 12:20:36AM +0100, Francesco Poli wrote: > On Mon, 13 Jan 2014 00:46:55 +0100 Ricardo Mones wrote: > > [...] > > On Sun, Jan 12, 2014 at 10:13:43PM +0100, Francesco Poli wrote: > [...] > > > You are still using ruby1.8 as system-wide default Ruby interpreter. > > > You should switch to ruby1.9.1 as default interpreter. > > > > Well, I have what it's pulled by apt-listbugs dependencies, which > > IMO should be able to pull the version of the interpreter necessary > > to run it, even if that includes switching default ruby. > > Please let me clarify: apt-listbugs depends on > "ruby | ruby-interpreter" and that's correct. > It works fine with both ruby1.8 and ruby1.9.1, as long as the required > libraries support the chosen Ruby interpreter. > > The fact is that ruby1.8 is deprecated and no longer supported > upstream: there's an ongoing transition to remove it from Debian. > Architecture-dependent Ruby libraries (such as ruby-debian) are being > recompiled without support for ruby1.8: that's the reason why > apt-listbugs stopped working with ruby1.8. > > In order to fix this situation, ruby1.8 no longer provides > "ruby-interpreter", so that packages like apt-listbugs will pull in > some other Ruby interpreter (such as ruby1.9.1). > This has already been implemented in ruby1.8/1.8.7.358-10 > > As I have already said, I think there's one last aspect to fix: ruby1.8 > should remove itself from the list of possible alternatives > for /usr/bin/ruby. > Dear ruby1.8 maintainers, do you agree?
The only case I can think of where ruby1.8 stays as /usr/bin/ruby after ruby1.9.1 is installed is the case where the user explicitly requested ruby1.8 to be the default alternative. Also, doing this will not fix upgrades from wheezy sinde there will be no new ruby1.8 that does not provides the alternatives entry to upgrade to. I indent to fix this situation by making `ruby` conflict with `ruby1.8`. -- Antonio Terceiro <terce...@debian.org>
signature.asc
Description: Digital signature
