Bug#639290: upgrade from squeeze to wheezy fails on i386 (pre-depends loop)
On Mon, Sep 12, 2011 at 14:03, Steve Langasek <vorlon@debian.org> wrote:
>> 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.
apt isn't "virtually" essential. Nothing in required depends on it as it is
just "important". It's just essential for apt because it thinks for itself
that it is goddamn important and marks itself essential, but if you install
stuff with dpkg directly you are "free" to break APT…
That bash was the worst example i could take, i already clarified in the log.
Maybe it gets better with zsh as login shell. Maybe i should have used the
"try to download a file from the web only with required packages" as the
"without wget/curl" is too easy (if all goes wrong: apt has a http transport).
Or for all vi/emacs lovers their preferred editor…
My whole point was that while there are tools which absolutely need to be
available its not a good idea to only handle these with care and just hope the
best for the others just because we could.
That we are doing something wrong, regardless of what we do can be seen
in #22550 and silbings - title says it all: "Packages are left in an
unconfigured state for a long time when installing many packages".
So, please pick your poison now.
> 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?
perl isn't pseudo essential. In fact APT would be happy in this case if it
would be as all it's dependencies would be pseudo-essential then, too, and
the problem is not really perl (consider the message a red hering) but that
a (pseudo) essential package as important as libc6 breaks this "leaf" package
with a bunch of even more "leafy" packages (in partial upgrades, the situation
changes in full upgrades: multiarch-support and libdb5.1 are essential then)
which in the end depend on our essential libc6 again.
So a "workaround" for this situation would be to follow Breaks to mark these
packages as essential, too, but given that a better solution is in the
pipeline i don't want to think about this - especially as enlarging the
pseudo essential set is likely causing problems in another scenarios.
In a very simplified essence: APT doesn't want to allow "leaf" packages to
be upgraded between unpack and configure of an essential package, but it has
"no problem" with it as soon as the other packages are essential, too.
>> 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 :)
I saw it there and i saw the reference to the debian-release discussion in
which a point-release upgrade was proposed as one of the "counter"-options,
but nobody said something against it, so i guessed it has some very
good and obvious reason so i just didn't cared enough to ask back then.
It just doesn't occurred to me that there are people out their who doesn't
upgrade from time to time… (professionally blinkered it seems), thanks!
Best regards
David Kalnischkies
P.S.: Upcoming experimental upload will have Chris branch merged, so this bug
will be closed with it. Just as a mild warning - this is obviously no fix for
the partial upgraders but i guess what to do about those is discussed and
handled elsewhere already.
Reply to: