Hi, * Axel Beckert <a...@debian.org> [140331 01:36]: > Hi, > > > * ruby: remove Breaks/Conflicts/Replaces against old interpreter packages > > as this will force the removal of old interpreters from users' systems > > (Closes: #740733) > > . > > The following upgrade scenarios from wheezy were tested, still work > > fine, > > and leave the old interpreters alone: > > - ruby > > - ruby + ruby1.8 > > - ruby + apt-listbugs > > - ruby + ruby1.8 + apt-listbugs > > - ruby1.8 + apt-listbugs > > I've just run into a scenario not listed above in which left me > without /usr/bin/ruby afterwards. This scenario is likely not > happening during an dist-upgrade from Wheezy to Jessie as it's planned > now, but may still hit other people who are running unstable. > > After I've read this changelog entry, I installed glark (which is > currently ruby1.8 only) again to notice when there's an updated > version working with a newer release of Ruby. [..] > I noticed that /usr/bin/ruby points back to ruby1.8: > update-alternatives: using /usr/bin/ruby1.8 to provide /usr/bin/ruby (ruby) > in auto mode > > I'm not sure if this is a bug in update-alternatives as it seems to > happily overwrite a file which was installed by a package -- I would > expect that it should prevent that.
One could argue that this is a bug in u-a, but u-a itself does not violate policy; certainly (now that ruby1.9.1, 2.0 have stopped being part of the scheme), ruby1.8 violates policy. > At least I think, it's worthwile to consider Marga's idea of uploading > ruby1.8 once more to remove that call to update-alternatives to > prevent this kind of issue. This really only helps users of unstable, and likely is quite some work (IIRC 1.8 now FTBFS). > Another option I can imagine is to keep the update-alternatives > mechanism for one more release but with just one alternative. > > ... or make update-alternatives not to overwrite package-installed > files. That's dpkg-divert's job. Keeping update-alternatives breaks when a user has previously manually chosen ruby1.8. I don't see a way out of this other than 1) cyclic dependencies 2) uploading an empty ruby1.8 package. Both of these options prevent users from keeping a working 1.8 interpreter, but because of update-alternatives in 1.8 this goal directly conflicts with any way of making any new version the new blessed default. > I'm neither sure where to actually file a bug report for that issue > nor which severity it should have (I can imagine everything, from > minor to grave -- as it deletes a file installed by another package). > Any advice or comment is appreciated. Cloning this bug with severity minor saying 'please allow keeping ruby1.8 installed [for stable users]' is probably welcome, but at this point I do not see how it's possible to do this. Thanks for the feedback, -- ,''`. Christian Hofstaedtler <z...@debian.org> : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `-
signature.asc
Description: Digital signature