Your message dated Fri, 24 Oct 2008 17:05:24 +0300 with message-id <4901D624.7080103@gmail.com> and subject line closing #60488 has caused the Debian Bug report #60488, regarding [libapt-pkg] internal error with --reinstall; analysis and possible strategy to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 60488: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=60488 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: internal error with --reinstall; analysis and possible strategy
- From: <james@netcsi.com>
- Date: Wed, 15 Mar 2000 19:38:10 -0500
- Message-id: <20000315193810.A1709@netcsi.com>
Package: apt Version: 0.3.18 I have two potato systems here, one i386, one powerpc. They have the following package versions installed: Package i386 powerpc apt 0.3.18 0.3.18 libc6 2.1.3-7 2.1.3-2 gzip 1.2.4-33 1.2.4-33 debianutils 1.13.2 1.13.2 They both have the problem: If I try # apt-get --reinstall install gzip debianutils it will proceed to fetch all the packages, then immediately abort with: E: Internal Error, Could not perform immediate configuraton (sic). As it turns out this error comes from about line 565 of packagemanager.cc. (This is modified source so the line is not exact; in any case it's the second occurrence of 'configuraton' in the file.) After adding loads and loads of extra debugging noise to libapt-pkg I managed to reconstruct the following sequence of events: 1) DepCache::Init marks everything already installed in the 'Keep' state as a default. 2) TryToInstall (in apt-get) tries to mark debianutils and gzip for install. DepCache::MarkInstall leaves their Mode as MarkKeep because the target version and installed version are the same. Noticing this, it sets a flag on them to make sure they get reinstalled even though they're marked the same as if they were held back, because --reinstall is being used. 3) PR::InstallProtect also tries marking both those packages for install, but there's no change. 4) The packages are ordered: first debianutils, then gzip. 5) PM::SmartUnpack is called on debianutils. All of debianutils' Pre-Depends (libc6) are ready. 6) debianutils is essential, so it has to be configured ASAP (immediate configuration). PM::SmartConfigure is called. 7) PM::SmartConfigure calls PM::DepAdd to make sure all debianutils' depends and pre-depends are ready. 8) PM::DepAdd looks at the depends and pre-depends and decides that the current version of libc6 satisfies all the dependencies. 9) Now PM::SmartUnpack is called on gzip. It too finds libc6 to be OK. 10) Since gzip is also essential, it too gets SmartConfigure'd. 11) SmartConfigure calls DepAdd. 12) DepAdd first goes past the first branch of its main loop tests (checking for 'now' packages that satisfy the dependencies). I think this is where it goes wrong. 13) Then it decides that the version it's looking at is not worth bothering over because it meets the following 3 conditions: the package is marked keep() it's all set up and doesn't need anything done it's the target version (not necessary but doesn't stop it given the other two) This is in a branch marked 'not the install version'. I find this rather odd, maybe the bug is actually here? 14) Since that's the only possible target version that can be downloaded, the dependency is unsatisfied and gzip is judged unconfigurable, and the whole thing just dies. I thought the problem was with the tests for IsNow(). I kep seeing tests like 'IsNow(Pkg) == true' but in the code for IsNow() you can see it returns a somewhat arbitrary nonzero number for true. Seems though that in C++ or the dialect of it that apt uses the type 'bool' has '==' overridden to compare truth values, since when I tried 'fixing' that it still didn't work. So the bug is somewhere else. I still think it's silly writing all these ' == false' and ' == true' comparisons when what you're comparing are truth values to begin with. You're only going to be giving yourselves RSIs doing things like that, and possibly introducing obscure bugs. Anyway, since my investigations haven't *quite* uncovered the bug yet, I thought someone who knows the code a *bit* better than me, who took his first look at apt internals yesterday, might be able to make a bit more sense out of what information I have managed to bring to light. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c.
--- End Message ---
--- Begin Message ---
- To: 60488-done@bugs.debian.org
- Subject: closing #60488
- From: "Eugene V. Lyubimkin" <jackyf.devel@gmail.com>
- Date: Fri, 24 Oct 2008 17:05:24 +0300
- Message-id: <4901D624.7080103@gmail.com>
More than 7 years old bug. Since --reinstall is working properly for a long time, I'm closing the bug. -- Eugene V. Lyubimkin aka JackYFAttachment: signature.asc
Description: OpenPGP digital signature
--- End Message ---