Hi Guillem, Guillem Jover wrote: > On Sun, 2009-05-03 at 16:21:17 +0300, Eugene V. Lyubimkin wrote: >> Package: dpkg >> Version: 1.14.26 >> Severity: normal >> >> Here is the relevant strings from upgrade log: >> >> -8<- >> Preparing to replace x11-common 1:7.3+18 (using >> .../x11-common_1:7.4+1_all.deb) ... >> Unpacking replacement x11-common ... >> Setting up x11-common (1:7.4+1) ... >> dpkg: regarding .../x11-utils_7.4+1_amd64.deb containing x11-utils, >> pre-dependency problem: >> x11-utils pre-depends on x11-common (>= 1:7.0.0) >> x11-common is unpacked, but has never been configured. >> dpkg: error processing /var/cache/apt/archives/x11-utils_7.4+1_amd64.deb >> (--unpack): >> pre-dependency problem - not installing x11-utils >> Errors were encountered while processing: >> /var/cache/apt/archives/x11-utils_7.4+1_amd64.deb >> ->8- > > What was the x11-utils version you were upgrading from? Unfortunately, this is pretty old log (back to start of May on other machine). If this is really important info, I'll dig and report it soon.
>> As you see, x11-common has just been properly unpacked and even >> configured, however it was in triggers-awaited stage after this >> failure: >> >> -8<- >> $ dpkg -l x11-common >> <...> >> iW x11-common 1:7.4+1 >> ->8- >> >> I suspect dpkg failed to realize this. > > I've not been able to reproduce this, and it's strange that this is > the first report of this, given that you say you've seen this several > times, but no one else has. It seems just no one called dpkg in such way earlier. As you might suspected, I use own dpkg frontend (Cupt), which indeed has different algorithm than libapt-pkg to generate dpkg call sequences. > Can you provide a reproducible case? Which package versions being > upgraded from and to. How are you calling dpkg? any specific front-end > used? etc. I think this situation can be reproduced by any upgradeable two packages, when one pre-depends on other, then you call 'dpkg --no-triggers install <slave_package>' 'dpkg --no-triggers install <master_package>' When the control passes to second command, the slave package must be in the 'iW' state. Are you able to reproduce this? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital signature
