On Wednesday, April 11, 2012 05:14:34, Thomas Goirand wrote: > On 04/11/2012 06:12 AM, Chris Knadle wrote: > > - if the init script left behind was part of a Debian package, deleting > > the init script means removing part of the configuration from the Debian > > pacakge, yet not purging the package it belongs to. This feels like > > something that would volate Debian policy regarding one package not > > altering the configuration of another. > > Likewise, moving the init script means that purging the old package > > that had configuration left behind will no longer delete the init > > script file, which will thus be left behind as orphaned cruft. > > You do realize that we are talking about leftovers from Etch (and > possibly earlier) in Wheezy, which means 4 or 5 years later, right? I don't disagree that the leftovers are old (whether it be from lenny or older)... but will the upgrade script check this? [Presumably the upgrade script would normally only check if the init script is dependency-based compatible, and not how old the init script is or whether it's associated with a Debian package.] > If you think that we can't delete them, how about moving them > away in a special folder, like /etc/init.d/obsolete-scripts (feel free > to propose a better name for that folder)? We could prompt the > user about them, so he wont miss it, and the "configuration" that > you are talking about will stay (even though, most likely, this is > quite useless, IMO). I think I agree with this proposition at least in spirit [I'm all for fixing the problem, afterall :-P], but I'm wondering whether this is the right thing to do or if there's maybe a better alternative. Personally, I'd rather give the user an option to purge the associated package the init script is in (if it's in one), especially if the package has been removed-but-not-purged. If that could be accomplished I think that would be a cleaner way of dealing with the problem. I think another option (which maybe could be used as a fallback) would be to leave the broken init script in place, but to 'chmod -x' the file to make it non-executable. [Would this work within the dependency-based framework?] > > - the upgrade may be unattended or automatic, in which case presumably > > the default will be chosen and the user/admin will never know that the > > init script was removed, so the default of 'yes' is dangerous. > > The default with "no" may be even more dangerous. If you run in a > non-interactive way, then you will still have some non-LSB header scripts > on the way, which may prevent you from booting. I'm trying to figure out a way this can be handled which will conform to Debian Policy section 6.3. Link for convenience: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s- controllingterminal Between us both, I think we've found that there's a problem with either default, which means this is going to be tricky to handle. :-/ > > - the current administrator at the keyboard may not be the one that > > wrote or installed the custom-installed init script, so the upgrade may > > need to be completed before the question of whether the init script can > > be deleted has a satisfactory answer, but an answer of 'no' will > > presumably cause an issue for dependency-based bootup. > > If we move the *bad* scripts away in a specific folder, we have best of > both worlds, IMO. > > Thoughts? It's better than deletion, but I'd also like to consdier alternatives. -- Chris -- Chris Knadle Chris.Knadle@coredump.us
Attachment:
signature.asc
Description: This is a digitally signed message part.