Bug#495954: [Pkg-openldap-devel] Bug#495954: slapd: Upgrade to Lenny failed: libldap_r-2.3.so.0 missing

[Sven Joachim <svenjoac@gmx.de>]

On 2008-08-21 23:38 +0200, Steve Langasek wrote:

> reassign 495954 aptitude
> thanks
>
> On Thu, Aug 21, 2008 at 11:24:01PM +0200, Ferenc Wagner wrote:
>> Steve Langasek <vorlon@debian.org> writes:
>
>> > On Thu, Aug 21, 2008 at 05:18:50PM +0200, Ferenc Wagner wrote:
>
>> >> I upgraded a machine from Etch to Lenny, and hit a problem with slapd:
>
>> >> 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
>
>> >> Indeed, libldap-2.3-0 has already been removed before this point.  I'm
>> >> rather confused about this, and don't understand how it's possible.
>> >> Unfortunately, all I can offer is the dpkg.log, if you are interested.
>
>> >> In the end I had to downgrade, remove slapd, upgrade, then watch the new
>> >> slapd fail to install as it can't read the ldif.  But that's only a
>> >> consequence, I guess.
>
>> > What did you use in order to effect the upgrade (e.g., apt, aptitude,...?)
>> > I'm afraid this is a bug in the package manager you used, which has removed
>> > libldap-2.3-0 before removing a package that depends on it.
>
>> I used aptitude interactively.  This would be a very serious bug in
>> it... If you can't see any other way, feel free to reassign this but
>> to aptitude.
>
> Well, it's an aptitude bug, so doing so.  The dependencies of the old
> version of the package *must* still be installed when the preinst of the new
> package is being run, because the new-preinst is called by dpkg in the phase
> when dpkg may still try to roll back to the old version on failure.

Can you back up this statement with a reference in the policy manual?
It seems that this may not always be possible, for instance when the old
version of the upgraded package was not configured.  OTOH, I found the
following statement in section 7.2:

          `Pre-Depends' are also required if the `preinst' script depends
          on the named package.  It is best to avoid this situation if
          possible.

It seems that this is just the situation here.  Compare also the
discussion around #469552/#314571, especially your own statement in
http://lists.debian.org/debian-devel/2008/07/msg01028.html.

Regards,
        Sven