On Wed, 15 Jan 2014 16:38:17 +0100 Antonio Terceiro wrote: > On Wed, Jan 15, 2014 at 12:20:36AM +0100, Francesco Poli wrote: [...] > > 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?
Hello Antonio, thanks for your reply. > > 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. That is exactly the situation I was thinking about. As long as ruby1.8 stays installed and is manually configured as the system-wide alternative for /usr/bin/ruby, many programs requiring architecture-dependent Ruby libraries will fail to work. This is why I was suggesting that ruby1.8 should remove itself from the list of available alternatives for /usr/bin/ruby ... > > 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. This is true, but I was thinking about continuously upgraded unstable/testing systems... > > I indent to fix this situation by making `ruby` conflict with `ruby1.8`. What if both ruby1.8 and ruby1.9.1 are already installed and ruby1.8 was previously (manually) configured as the system-wide alternative for /usr/bin/ruby? Which package will pull in ruby, thus forcing the removal of ruby1.8? All packages depending on "ruby | ruby-interpreter" will be satisfied by ruby1.9.1, if I understand correctly... Is there a way to fix this scenario too? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpI14wvg9GBt.pgp
Description: PGP signature
