On Sun, Sep 2, 2012 at 6:29 PM, Guillem Jover <[email protected]> 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). There was a "similar" bug I fixed earlier last week in the not-pseudo- essential path which was the reverse: APT never unpacked an already unpacked package even if it wanted to install a different version usually screwing your system further as you went from 'same file with different hash' to 'different versions of an M-A:same package should be configured'. 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.) The libpam-modules example above e.g. gives me a dpkg error on unpacking: dpkg: error processing libpam-modules_1.1.3-7.1_amd64.deb (--unpack): trying to overwrite shared '/etc/security/time.conf', which is different from other instances of package libpam-modules:amd64 i386 is unpacked, unpacking amd64 -- the other way around same error with a different file (/etc/security/limits.conf). I don't remember changing these files - noting that :i386 wasn't installed on my system previously. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
