Debhelper-generated postinst and prerm vs. manual one

Henrique de Moraes Holschuh hmh at debian.org
Sat Oct 21 03:05:31 UTC 2006


On Fri, 20 Oct 2006, Roberto C. Sanchez wrote:
> I disagree.  Please take another look at #257181.  While I understand

The bug submitter is misguided by the bad naming of "START"... It should be
"ENABLE", I suppose.

> that if START=yes is not set, the daemon is disabled, I don't think that
> the exit code if `invoke-rc.d saslauthd start` should be 0 if the daemon

invoke-rc.d is NOT TO BE USED by anything other than maintainer scripts and
other Debian infrastructure.  Just so you know that... as the father of
invoke-rc.d I am quite wary from letting it go the way of the !#@$$
update-rc.d.

> of the components of that script is start saslauthd.  You naively write
> `invoke-rc.d saslauthd start` and expect that a successful exit means
> that the daemon actually started.

You have a bug in the stuff you wrote, then. First, it should not be using
invoke-rc.d unless it *needs* the semanthics of invoke-rc.d, one of which is
that whatever you ask invoke-rc.d can be ignored or changed by local system
configuration.  Second, if saslauth is not *enabled* by the configuration,
it won't work, and if your script needs it to work, it should be sourcing
the configuration file and complaining that it is not enabled.

What we really need is an exit code for "disabled", which we don't support
in Debian.  Maybe we can fix this for Etch+1, but for Etch, that code is
exit status *zero*.  I am wearing my sysvinit co-maintainer hat when I say
this.

> The only case where this does not hold is on install, since dpkg will
> fail to finish installing the package if the script exits with a
> non-zero exit code.

I have had a fight over this with the dh_install init maintainer. Basically,
it *depends on the package* wether a failure of a initscript in postinst
should abort everything or not.

If the initscript is *expected* to fail in upgrades (like the Cyrus imapd
one, for example), then debhelper is wrong if it causes a postinst abort
(since it cannot be configured otherwise, this means we don't let debhelper
generate the helper script to call the initscript).

> However, I don't think that means that if it stays disabled and someone
> or something tries to start it and fails that is somehow not an error.

We don't have a better choice right now.  We can fix this Debian-wide for
Etch+1.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



More information about the Pkg-cyrus-sasl2-debian-devel mailing list