Re: Packages not removable because the `/etc/init.d/package stop' fails.
On Fri, Jul 11, 2008 at 10:52:36PM -0700, Russ Allbery wrote: Russ Allbery [EMAIL PROTECTED] writes: Well, it's an RC bug (violation of the must in Policy 9.3.2) for the stop action of an init script to fail if the daemon is not running, which is fairly serious. I think it could well warrant a stable update if it's causing problems for upgrades to lenny. Actually, I take that back -- it's not on the lenny RC bug list, so it's possibly not an RC bug. It would be if Policy and the release goals were synchronized and the must stayed in that case, but it's ambiguous right now. If this truly shouldn't be RC, Policy should be changed to make sane init script behavior a should instead. It was ambiguous before the latest policy commit because reasonable people could disagree about what sane behavior of an init script was, but in practice, bugs that prevent a package from being upgradeable (such as missing conflicts/replaces, broken maintainer scripts that fail to handle the previous package version, etc.) have always been considered de facto RC in the past, regardless of whether they're policy violations. I don't see any evidence that the release team has changed this practice for lenny. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages not removable because the `/etc/init.d/package stop' fails.
Le Fri, Jul 11, 2008 at 10:45:39PM -0700, Russ Allbery a écrit : Charles Plessy [EMAIL PROTECTED] writes: As a result, if the daemon is not running, postrm fails and the package can not be removed. See #489366 for example. Now I wonder how to deal with that kind of problem. It could be solved at the package level, except that such bug but is probably not grave enough for the package to be updated in Etch. Well, it's an RC bug (violation of the must in Policy 9.3.2) for the stop action of an init script to fail if the daemon is not running, which is fairly serious. I eventually realised that the reason why peercast-servent fails to be removed when the peercast daemon is not running is because the package uses an /etc/init.d template from dh_make, that calls start-stop-daemon without --oknodo. The bug is fixed in Lenny and Sid. I will raise the priority to serious, and mark it as fixed in the relevant versions. I guess that similar bugs are around, but apparently this has been discussed this month in a thread that I skipped reading because at that time I was wondering if 'Oknodo' was the name of a tropical island. Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages not removable because the `/etc/init.d/package stop' fails.
Charles Plessy [EMAIL PROTECTED] writes: It seems that some packaged daemons use a combination of scripts that sometimes makes them difficult to remove on Etch: - prerm stops the daemon and exits if it fails This is generally correct. If the daemon can't shut down cleanly, continuing with the upgrade anyway could result in data corruption or loss depending on the daemon. I think it's the correct conservative behavior to stop at that point and force manual intervention. - /etc/init.d/package stops the daemon using start-stop-daemon and fails if it was not running. This isn't correct. As a result, if the daemon is not running, postrm fails and the package can not be removed. See #489366 for example. Now I wonder how to deal with that kind of problem. It could be solved at the package level, except that such bug but is probably not grave enough for the package to be updated in Etch. Well, it's an RC bug (violation of the must in Policy 9.3.2) for the stop action of an init script to fail if the daemon is not running, which is fairly serious. I think it could well warrant a stable update if it's causing problems for upgrades to lenny. The other option is to work around it in the upgraded version of the package; if the prerm script fails, there's an error handling case that calls the new prerm script with the failed-upgrade argument and gives it an opportunity to say yes, I don't care, continue anyway. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages not removable because the `/etc/init.d/package stop' fails.
Russ Allbery [EMAIL PROTECTED] writes: Well, it's an RC bug (violation of the must in Policy 9.3.2) for the stop action of an init script to fail if the daemon is not running, which is fairly serious. I think it could well warrant a stable update if it's causing problems for upgrades to lenny. Actually, I take that back -- it's not on the lenny RC bug list, so it's possibly not an RC bug. It would be if Policy and the release goals were synchronized and the must stayed in that case, but it's ambiguous right now. If this truly shouldn't be RC, Policy should be changed to make sane init script behavior a should instead. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
