Bug#495954: slapd: Upgrade to Lenny failed: libldap_r-2.3.so.0 missing

[Ferenc Wagner <wferi@niif.hu>]

Daniel Burrows <dburrows@debian.org> writes:

> On Sat, Aug 23, 2008 at 08:30:14PM +0200, Ferenc Wagner <wferi@niif.hu> was heard to say:
>> Daniel Burrows <dburrows@debian.org> writes:
>>>     2. A typescript of the upgrade with "-o Debug::pkgDpkgPM=true"
>>>        added (both to get more debugging information and to see what
>>>        happened in the install sequence before slapd was removed).
>>>        If you're worried about messing up your system, you could
>>>        temporarily replace dpkg with a symlink to /bin/true.
>> 
>> The system is already upgraded, so I can't easily provide a
>> typescript (and was stupid not to record one in the first time).
>> However, I can try reproducing the issue based on my backups if
>> necessary.  For the easy part, maybe this helps somewhat:
>
> The typescript would be very useful for this bug.  I can make a few
> guesses based on the dpkg log, but nothing definitive.
>
>> $ egrep 'libldap|slapd' /var/log/dpkg.log
>
>   [snip]
>
>> 2008-08-21 13:48:15 status unpacked libldap2-dev 2.4.10-3
>> 2008-08-21 13:48:16 status installed libldap2 2.1.30-13.3
>> 2008-08-21 13:48:16 remove libldap2 2.1.30-13.3 2.1.30-13.3
>
>   I think this is where we remove libldap2; I'm not very familiar with
> dpkg.log's format.
>
>> 2008-08-21 13:50:13 status installed libldap-2.4-2 2.4.10-3
>> 2008-08-21 13:50:34 status unpacked libldap2-dev 2.4.10-3
>> 2008-08-21 13:50:34 status half-configured libldap2-dev 2.4.10-3
>> 2008-08-21 13:50:34 status installed libldap2-dev 2.4.10-3
>> (next aptitude run)
>> 2008-08-21 13:52:25 upgrade slapd 2.3.30-5+etch1 2.4.10-3
>> 2008-08-21 13:52:25 status half-installed slapd 2.3.30-5+etch1
>> 2008-08-21 13:52:28 status unpacked slapd 2.3.30-5+etch1
>
> Do you mean the next time aptitude ran dpkg, or did you actually
> tell aptitude a second time to install packages?
>
> I don't know if dpkg.log can tell you this, but did any packages
> fail to install or configure between the two "runs"?

I tried the upgrade with aptitude, but that exited with an error,
because it could not upgrade slapd:

Errors were encountered while processing:
 libperl5.10
 tomcat5.5-admin
 slapd
 perl
 apache2.2-common
 perl-modules
 apache2-mpm-prefork
 apache2-threaded-dev

Then I restarted aptitude and retried the same operation.  That
happened at 13:51, as the aptitude log shows (that's why I included
the prelude of the next run in that excerpt).  That run was very
short, of course, exiting at once with

Preparing to replace slapd 2.3.30-5+etch1 (using .../slapd_2.4.10-3_i386.deb) ...
  Dumping to /var/backups/slapd-2.3.30-5+etch1: 
  - directory dc=aai,dc=niif,dc=hu... slapcat: error while loading shared libraries: libldap_r-2.3.so.0: cannot open shared object file: No such file or directory
failed.
dpkg: error processing /var/cache/apt/archives/slapd_2.4.10-3_i386.deb (--unpack):
 subprocess pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/slapd_2.4.10-3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Then I retargeted Etch, downgraded/replaced just enough packages to
get slapd in a decent state, then removed it, and after this the
upgrade finished without a single problem.  Then I tried to install
slapd, but that again didn't work as it could not import the database.

>>> I doubt this is an aptitude bug -- most likely it has to do with
>>> what arguments are being passed to dpkg, and that all lives in apt.
>>> But I'm leaving this afternoon to go on vacation for a week, so
>>> someone else may have to reassign it once we've confirmed that.
>> 
>> Does the above confirm that?  As a next step, I'd try installing a new
>> Etch system with slapd and upgrade that.  If that does not reproduce
>> the problem, can you recommend a procedure to better approximate the
>> original package state based on some status files from backup for
>> example?
>
> I think it pretty much confirms this: particularly the fact that
> aptitude believes that it's installing the required new package.  That
> means that at some point, the lower layers in apt are turning this into
> two dpkg runs, and breaking them up in a way that doesn't respect
> dependencies.

I'm not quite sure, as the break corresponds to two aptitude runs.

> Debugging output from apt would be an even stronger indication, but
> I think that the logs you provided are good enough.  I'll reassign this --
> maybe someone will have time to look into it, or maybe I can put my apt
> hat on next week and try to solve it.
>
> If the bug is related to upgrading a package and simultaneously
> removing one of its dependencies,

That seems to sum it up nicely: slapd changed dependencies, and I
elected to remove the old one.

> one workaround would be to pass "-o Aptitude::Delete-Unused=true"
> on the command-line for the upgrade, and then to run "aptitude
> install" afterwards to clear out the unused packages.  This wouldn't
> actually fix the problem, but it would reduce the likelihood of it
> cropping up until we have a proper fix.

OK.
-- 
Thanks,
Feri.