Hey Russ... On Thu, 2010-07-29 at 15:14 -0700, Russ Allbery wrote: > It's normal in Debian for init scripts to be left behind after packages > are removed, since Debian's package management system retains > configuration files by default (which includes init scripts). This is > true across a wide variety of configuration files, and you'll find several > statements in Policy requiring that the system behave reasonably (not > produce lots of errors) in this state. Yes, I've read that.... > This is a design principle and design goal for Debian that goes beyond > just init scripts. Having a package removed but not purged should not > cause errors, send the administrator mail from cron jobs, and so forth. I just wanted two things well three... ;) 1) Suggesting that it's a good idea to at least suggest usage of LSB init script exit codes 2) At least let initscripts allow to fail (when the package is removed), if there's strong reason for them (as e.g. in my dm-crypt example). 3) Suggest to reconsider the above for initscripts. It's absolutely reasonable that left over configuration files shouldn't be allowed to break anything. But IMO it does not in the case of initscripts. You just get the warning message,.. but everything's fine. > > With dependency based boot it could even harm, that such scripts are > > there but don't fail. > Package dependencies are not satisfied if the other package only has > config files installed, and package dependencies are the correct way of > solving this problem. Uhm... ok... Imagine a package using the status action from another facility to find whether it's running or not. If it runs, it starts its own daemon with different options e.g. to make use of that daemon. Now even if status is implemented,... the package of the initscript might be removed (!purged)... we get exit 0 then. The script believes the status would run. It does however not. Cheers, Chris :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature