On Sat, Aug 23, 2008 at 08:30:14PM +0200, Ferenc Wagner <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> 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) 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"? > 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 > > 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. 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, 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. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
