tl;dr-version: From an APT point of view: Yes, please move this breakage of non-essential tools away from a pseudo-essential package for the sake of partial upgrades (and in the long run maybe also non-partial, who knows). On Sun, Sep 4, 2011 at 03:55, Steve Langasek <vorlon@debian.org> wrote: > Once I tried with a clean i386 debootstrap, Adam's test case was sufficient. > I have not yet tested to see whether wheezy's apt can handle this scenario; > I still will, but Michal's comment seems pretty decisive: APT currently in wheezy can't as well (as it's more or less the same code). Quiet a few very complex problems with the ordering are "well" known - so well that we even had a GSoC project this year to have someone to work on these longstanding issues. And indeed a few preliminary tests with Chris Baines code are promising that even this specific problem is fixed (and the follow-up "error", even through APT ignores this one for the sake of the universe) The situation is a bit complicated so i will spare details and instead just refer to the attached stripped down testcase (if you want, download apt sources, build them, move the testcase into test/integration and run it). The error message is not the same and the packages involved are a squeeze to unstable upgrade (libdb5.1 is only in unstable for now), but its similar and the original problem is to hard to setup in a minimal environment (yes, if you want to debug ordering even a minimal chroot is too big…). In essence: The dependency-tree libc6 breaks perl depends libdb5.1 pre-depends multiarch-support depends libc6 can't be ordered in an immediate configuration setup as long as libdb5.1 (and therefore multiarch-support) isn't (pseudo) essential in this setup (it will be thanks to e.g. pam-stuff in wheezy) which it is not in a partial upgrade. The human solution to just unpack perl sounds very easy - but only because we know that it is not a big deal, for APT breaking a bunch of dependencies is a big deal. Would you be equally willing to unpack lets say bash without a clear idea then you are able to configure it again [0]? (or X? APT? libc6?) And bash has properly far less dependencies… So the code doesn't consider it as an option to unpack without the target to configure it soon as long as immediate configuration is enabled. Suddenly the config-option name makes sense… Immediate vs "i don't know then i will be able to…" Best regards David Kalnischkies [0] This is what is fixed in the GSoC code by Chris, APT can look ahead what it has to do - and it knows that it can do more than on action at once, so it can offload cycles to dpkg which is better in breaking them as it knows which packages doesn't have maintainer-scripts… P.S.: Yes, this tl;dr-text is really the "spare details" version. I am accepting pre-orders for the full-size non-fiction novel edition… (through delivery has to wait until my exams are over, which is also the reason why i am so late for the party…) P.P.S.: If someone can tell me (maybe off-list) why we just can't upload a fixed libc6 (and co.) in a point-release for squeeze instead of this trickery with multiarch-support, feel free to do so, i would appreciate it.
Attachment:
test-perl
Description: Binary data