[Pkg-openldap-devel] Bug#596100: When told not to initially configure slapd, (un-)installation fails due to init script return code.

[Steve Langasek]

On Thu, Sep 09, 2010 at 12:10:22PM +0100, Matthew King wrote:
> - The postinst could not attempt to start a daemon which is installed
> but not configured.

> I checked postfix and that's exactly what it does:

> (at the end of postinst)
> if [ "$mailer" != "No configuration" ] || [ -f /etc/postfix/main.cf ]; then
>     ...
>     # start postfix
>     ...
> fi

Adding more complexity to maintainer scripts is the wrong answer.

> I don't agree with the initial problem that a package is not installed
> until after it's configured _even though_ the administrator has chosen
> explicitly not to configure it at that time. I can see the point of not
> creating the sentinel file, but in that case not even running the init
> script would seem the best answer. Unfortunately I can't see any way to
> do that and still use debhelper.

You would achieve "not even running the init script" by implementing a
policy-rc.d that says not to run init scripts, which was my first suggestion
in response to the problem you posed.

> Moreover, it doesn't just affect chef, it affects apt and by extension
> potentially everything. Any other packages which are being installed at
> the same time may also be left in a half-configured state when slapd
> fails to start and brings down apt-get.

If you don't want to have to deal with the apt fallout from overriding
slapd's default initial directory configuration, then /don't do that/.  I am
not at all sympathetic to users who insist on configuring packages the hard
way and then complain that it's too hard.  I'm not saying this is
applicable in your case; there are obvious reasons to use a tool like chef
for configuration management.  But I do from time to time get bug reports
like this on various packages from people not using configuration management
tools, who expect maintainers to put in the effort to make the package as
easy to use without automatic configuration as it is with automatic
configuration, and that's just not realistic.  I don't want my packages to
lie to the package manager and claim that they're in a configured state when
they are not, even though this would obviously be convenient when using
apt-get.

Anyway, I've just committed a fix for the failure to remove unconfigured
slapd, which is the part of this report that I consider a real bug (and the
part that warrants RC severity).  So this bug report will be closed in the
next upload.  If one of my fellow OpenLDAP comaintainers disagrees strongly
with my position on handling of manually-configured packages, I trust they
will clone and reopen this bug report at a lower severity.

-- 
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 Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20100912/e2362ec0/attachment.pgp>