Marco d'Itri wrote: > On Apr 09, Roger Leigh <rle...@codelibre.net> wrote: > > majority, it's going to be increasingly untested. Do we want to > > continue to maintain something that will be increasingly > > unsupportable, or complete the migration cleanly before that point? > Kill it. With fire.
Yes please. > > WRT actually doing this, the main issues I can see are > I say just abort the upgrade and let root deal with the issues found, > it's better than risking clobbering some local change. To the extent root caused the problem in the first place with local scripts. The vast majority of such cases seem like issues caused by Debian packages, as mentioned below. > > - blocking by obsolete-but-unpurged init scripts without LSB header. > > We could mv them out of the way to .dpkg-old and continue, or > > abort and require manual intervention. > Or just say in the release notes that it's a good idea to run something > like this before upgrading: > > dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge Personally, I run into more problems by upgrading packages that drop or rename init scripts (and other conffiles). dpkg keeps the old files around even if unmodified, and leaves them associated with the package despite no longer appearing in that package. (This also makes them difficult to track down and eliminate.) I'd like to question that particular decision of dpkg; I think it causes more pain than help. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120410184941.GA10156@leaf