On Mon, Sep 3, 2012 at 8:42 PM, Guillem Jover <guillem@debian.org> wrote: > On Mon, 2012-09-03 at 13:26:27 +0200, David Kalnischkies wrote: >> On Sun, Sep 2, 2012 at 6:29 PM, Guillem Jover <guillem@debian.org> wrote: >> > On Mon, 2012-04-30 at 09:52:43 +0200, Martin Steigerwald wrote: >> > I think this bug report should be serious, because once hit, apt cannot >> > recover itself in any way, it is pretty easy to get into, and the only >> > way to proceed is to run for example: «dpkg --configure --pending», >> > but that might not be enough if the dependencies are not satisfiable. >> >> Predependency for reproducing this seems to be that the unpacked package >> is (pseudo)essential. The thing is that APT tries to unpack a package, >> which is already unpacked, but it earlier decided that it doesn't need >> to download the package as it already here (unpacked) - so you see >> this error as APT can't find the file as it didn't download it >> (at least not in its usual location in your example). > > It seems to be something else (?), in my tests I had the downloaded > packages in my apt cache but didn't include that in the session log, > sorry about that, here's another way to reproduce (with the packages > referred by this same bug report): I noticed that is not enough that the file is in the right place, APT also needed to request it to have its filename stored internally - but as the first stage sees that it is already installed it assumes it doesn't need to download it again and therefore not requested. The later stage didn't check as described above if the package was already unpacked therefore suddenly requiring the filename for unpack => BOOM. > The thing is that this only happens when two (or more?) instances are > involved, if there's only one then apt knows how to configure them > correctly. Yeap. There is a special path for pseudo-essential (as gcc-4.7-base is, too) M-A: same packages to ensure that all packages in this group are unpacked and configured in lock-step as dpkg would otherwise be really unhappy about different versions being unpacked/configured - as you probably know. ;) >> I will opportunistically close this bugreport with these two changes then, >> even through I couldn't reproduce either. >> (I am hopefully able to try a bit harder later today.) > > Hope the new session helps you with this. Yes, thanks! I could reproduce it with 0.9.7.4 and it is gone in my local build. :) The joy of forgetting that the installed version is a self-built one with the wrong version number … Best regards David Kalnischkies
Attachment:
apt-670900-internal-error-filename-unneeded-unpack.diff
Description: Binary data