Debhelper-generated postinst and prerm vs. manual one

[Roberto C. Sanchez]

On Sat, Oct 21, 2006 at 12:05:31AM -0300, Henrique de Moraes Holschuh wrote:
> 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.
> 
Except that the init script would then need to check for both.  I don't
suppose it is a big issue, but we would still need to check for the
presence of START=yes so that upgraded installations do not break.

> > 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.
> 
Sorry, I just using it as an example.  You can simple pretend something
like the following:

s/invoke-rc\.d /\/etc\/init.d\//g

> > 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

OK.

> 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.
> 
Except that this is horribly platform dependent.  I mean, it is not
realistic to expect that some developer somewhere is going to bother
writing his script so that if it detects it is being run on Debian it
will source /etc/defaults/saslauthd and look for stuff in there.

> 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.
> 
I understand.  However, I think that is horribly broken.  If I run
`/etc/init.d/saslauthd start` (note I did not use invoke-rc.d) and the
daemon does not start, it is *wrong* to exit with a zero exit code.  I
don't care what the policy or standard is, it is broken.

> > 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).
> 

I would be willing to go that route.  It would simplify our init script
quite a bit.

> > 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.
> 
Yes, but will that Debian-wide fix be "standard" outside of Debian?  I'm
most concerned about portability of non-Debian specific scripts.  That
is, if someone writes a script which expects "standard" semantics, will
the solution you are talking about break that?

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20061021/df025f30/attachment.pgp