]] Ian Jackson Hi,
> There may be good reasons not to treat daemon startup failure as a > postinst failure, but the argument above is not one of them. I think this is the core question. I largely agree with Ian here that having postinsts fail is not that big a deal if they can't make forward progress, but also we're being asked to advice on what happens when a maintainer script fails to restart a service. I disagree with him on whether failure to start/restart a service should be considered a configuration failure. The API provided by a package being in the configured state is not whether the relevant daemon is running or not; that is runtime and can and will change many times while the package is in the configured state, so dpkg dependencies are not useful for expressing «this service must be running». (There's also the case where the service is running on a separate host, which is often the case for services such as databases and where the use of Depends is inappropriate.) I think the general rule should be that the success/failure of the postinst script should signal whether the package considers itself ready to provide whatever API it exists to provide (disregarding the case of Essential packages here, since those are special). This means that failure to start a daemon should generally not cause the postinst to fail. At the same time, I think there are exceptions to this rule that should be left to maintainer judgement: sshd comes to mind as a service where if it can't restart, you want the system to make it very clear that something is wrong that you might want to fix sooner rather than later (since failure to do so can lead to you not being able to access it after a reboot). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are