Bug#548858: apt fails to upgrade
Michael Vogt
[..]
> ithrandir:~# apt-get upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
[..]
> 46 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
> Need to get 0B/49.6MB of archives.
> After this operation, 541kB of additional disk space will be used.
> Do you want to continue [Y/n]?
> E: Internal Error, Could not perform immediate configuration (2) on perl
>
> Same with aptitude and anything else
[..]
The ordering algorithm is failing here (its too agressive when
propergating the Immediate flag), the attached patch seems to fix the
problem (and thanks to David Kalnischkies who debugged the failure
with me).
Cheers,
Michael
David Kalnischkies
severity 548858 normal
thx
For your information:
APT tries to be over correct and want to ensure that essential and
important packages can be configured and this as fast as possible.
It does add an immediate flag to all these packages (since a long time)
and to all dependencies of these packages (since apt 0.7.10).
The situation here is/was:
perl depends on perl-modules
perl-modules depends on perl
(both needing a newer version than the one installed)
and perl gets the immediate flag as of a (long) dependency line
(and propagate it also to perl-modules).
This immediate flag promotes a normal depends to something
like a pre-dependency - and now you have a problem:
You have two packages predepending on each other.
A workaround for you to upgrade in such a situation would be:
apt-get dist-upgrade -o APT::Immediate-Configure=0
This deactivates this immediate configuration option (temporary).
The problem itself here reported should be vanished, as
liblocale-gettext-perl does now pre-depends on perl-base instead of perl
(see #548848) again and perl and perl-modules are therefore no longer
pseudo-essentials. The old dependency line which made perl
pseudo-essential was: (util-linux -> tzdata ->)
debconf -> debconf-l18n -> liblocale-gettext-perl -> perl
APT enforce with this immediate configuration for example that each
essential or important package is configured before all the other packages
are even unpacked to limit the effect of a failing dpkg operation
(dealing with an unrelated package).
This is also why the patch above is not the best possible solution:
As the patch only consider updated packages to pass the flag on perl
would be not pseudo-essential any more, so in between the dpkg unpack and
configure operation could be "years". If in between a totally unimportant
package generates only the smallest dpkg fail perl would be not configured.
This means all packages depending on perl maybe doesn't work now:
debconf could fail miserable now as the dependencies of his dependencies
are no longer satisfied - bad isn't it?
At a first step Michael and i will most likely change the message to be
more friendly (and translateable) and add more details to the option
description in apt.conf. Further steps need to be discussed and
implemented (if possible), but as this is a quite complex topic it will
need time - if anybody has an idea how to fix this, feel free to contribute. :)
Best regards / Mit freundlichen Grüßen,
David "DonKult" Kalnischkies
P.S.: regarding severity:
As the bug report here was caused by a mistake in another package and
dependency-cycles - exspecially tight versioned once - are very rare
between (pseudo-)essential/important packages (remember, flag propagation
was introduced with 0.7.10 - this is more than a year ago and it never
happend until now - and now it doesn't really happen either)
i downgrade the severity to normal as this bug exists more or less only
in theory and a proper and easy "workaround" exists also, which just need
to be documented a bit more and is therefore in my eyes not important
enough to block testing migration.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org