On 04/10/2012 07:03 AM, 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. >
I wholeheartedly agree. I also agree that wheezy would be the correct moment to do it, and that we shouldn't wait until wheezy+1. >> 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. > Considering that most (if not all) scripts would be user custom-scripts, I'd say that the best way would be to, just move them away on a special folder, and execute them one by one, without any particular order, and print a huge warning at boot time, saying: HEY, we've found crap, please fix! It's there ---> $whatever-obsolete-script-path Of course, that's not ideal, but I believe that'd be our best hope to not destroy *too much* old setups during upgrades. My bet is that most user-made scripts would not require any dependencies anyway. Also, doing the last upgrades of some old boxes, I've myself found that I had some rotten bind 8 init scripts, because bind 8 was removed, but not purged. That goes on the way to the user (and that annoyed me quite a bit). I believe that for packages that have been removed but not purged, it's very very likely that the remaining init.d script isn't wanted by the user. I'd be for deleting those with a small warning (or even better, a debconf message with something like: do you want to delete these antediluvian scripts that are still in your box? yes/no with yes as default). Thoughts? Am I doing too many assumptions here, and thinking too much that everyone is facing the same situation I did? Thomas Goirand (zigo) -- 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/4f84032c.1040...@debian.org