Debhelper-generated postinst and prerm vs. manual one
Roberto C. Sanchez
roberto at connexer.com
Sat Oct 21 07:06:57 UTC 2006
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
More information about the Pkg-cyrus-sasl2-debian-devel
mailing list