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

[Matthew King]

Steve Langasek <vorlon at debian.org> writes:

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

It would be achieved for every package, whether desired or not. If 2 or
more daemons are being installed, the only option available is to not
start any or attempt to start them all, purely because the openldap
postinst script tries to start slapd _EVEN THOUGH_ it is well aware that
it won't work and furthermore will terminate the entire package
installation process, a process which is not related to whether slapd is
configured or not.

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

If the option were 'do you want to kill apt prematurely?' then fine, but
the option is only 'do you want to configure slapd automatically or do
it yourself later?'

Configuring slapd the hard way would first start with building my own
binaries, which I am not proposing to do. What I want is to leave
slapd's configuration empty _without breaking the rest of the system_.

> 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

I don't see why not. I managed it and sent a patch. Discussion has
indicated that the method the patch used was not satisfactory but I am
happy to hack up an alternative when I am sure of the direction you as
the maintainer would like it to take.

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

But they _are_ in a configured state, as far as debconf is
concerned. The extent to which debconf has been told to configure slapd
is 'not at all', and that is exactly what it has done.

There is precedent for doing this. Many daemons will put an equivalent
of the sentinel file or variable in place until they are configured
after apt has finished with them.

I don't expect debconf to look after /etc/exports, or to configure every
aspect of Apache, but I also don't expect apt/dpkg to fail because there
are no NFS exports or because vhost and ssl configuration is not done.

Similarly, many web applications will ask if the administrator would
like to set up the web server to enable the application. They also don't
cause the entirety of apt/dpkg to fail until the application's apache
configuration is activated.

Perhaps if debconf were the registry it could be expected to configure
every aspect of every part of the system. It would also follow in that
case that a minor change should naturally cause catastrophic failure.

> 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

Good news.

I can concede that fixing the failure to install in an exceptional case
is not something that should hold squeeze back, but I don't think it's
not a bug. Not until that registry goal is achieved and "that's not a
bug it's a feature" becomes SOP for Debian.

Matthew

-- 
I must take issue with the term "a mere child", for it has been my
invariable experience that the company of a mere child is infinitely
preferable to that of a mere adult.
                                           --  Fran Lebowitz