On Wed, Jan 15, 2014 at 09:48:57PM +0100, Francesco Poli wrote: > 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?
You are right! I will do another "last upload" of ruby1.8 dropping the alternatives entries ... :-/ -- Antonio Terceiro <terce...@debian.org>
signature.asc
Description: Digital signature
