Hi David, Thanks for the explanations!
On Sun, Sep 04, 2011 at 02:50:58PM +0200, David Kalnischkies wrote: > 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… bash - no, because it's essential. perl is not, so breaking it during the upgrade should be considered acceptable (or at least, should be considered). X could be broken during upgrade. apt should be virtually essential. libc6 is pseudo-essential. Is there some reason for perl specifically to be treated as virtually essential here, or is immediate configuration being applied to all packages with a certain number of reverse-dependencies installed? > 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. We can't rely on users to apply, or even have access to, packages published in -updates before they upgrade between releases. Occasionally we have recommended inter-release upgrade paths that involve pulling packages from -updates or from a release-upgrade suite, but the failure mode for not following the directions is just that you will have to sort out the upgrade path manually. Dropping the multiarch-support pre-depends, with the result that users who skip pulling from -updates have a completely broken and unbootable system due to an undeclared dependency relationship, isn't a very palatable solution. Anyway, I did ask for feedback on debian-devel before introducing this Pre-Depends; if you would like to propose a better way to address the problem, feel free to follow up there :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
