Re: Need help sorting out apt-get behavior during upgrade
Hi!
On Tue, Mar 27, 2012 at 22:21, Stefan Fritsch <sf@debian.org> wrote:
> Instead of upgrading the apache2 package, apt-get removes it. What is
> very strange is that apt-get installs the new apache2-data package but
> in the end does not install any package that depends on apache2-data.
> This looks like a bug to me.
It's a longstanding bug that we do not undo steps we took then APT
decides against a specific action. In your case it decides against
installing the package which depends on apache2-data.
For the most simple cases we have some heuristics now to dispose
the obvious "mistakes", but in general we miss the record of changes
we did caused by a specific package to undo these actions -
disadvantage of deploying a greedy algorithm…
> But the main issue is why does apt-get remove apache2? apache2-bin
> conflicts&replaces apache2.2-bin. According to policy 7.6.2, this
> should allow apt to determine which package to keep and which to
> remove. But it chooses to keep apache2.2-bin and not install apache2-
> bin. Does apt-get implement the logic from policy 7.6.2? If no, maybe
> you can get that section changed in the policy to reflect reality?
It does (in a way), but 7.6.2 doesn't apply here as it doesn't talk at all
about upgrades -- and is coupled with Provides.
In your train of thought APT would flip between mawk and gawk all the time
given that they both provide awk and conflict+replaces each other.
7.6.2 just tells us that mawk can step in as gawk replacement and v.v.,
but not that it should do it on an upgrade unrequested…
And even if it is requested by another package, you still don't want to
flip your MTA from exim4 to postfix usually just because on package
wants that…
Something which is as obvious to a human as this package rename
is just impossible currently to tell your beloved package manager.
(Beside that an apache2.2 -> apache2 upgrade isn't that obvious
for a human either, but for different reasons)
> BTW, it works fine with aptitude.
If the force is big (e.g. because the user requested it) APT will comply
as you can see with 'apt-get install apache2' but without force
it will try to determine which route is the one which will cause the least
amount of removed functionality (and removing a package is such a loose,
so APT decides against removing apache2.2-bin in favor of apache2-bin -
the rest is just a logical consequence out of this decision.
In this specific scenario we end up with a pretty silly solution through:
aptitude is better here as it looks at the complete solutions to decide
which one to take rather then decide on a package vs package basis)
For APT is this 'dist-upgrade' vs. 'install apache2' the same
conflict resolution but the later has the "expected" results as the
weights are different. As the scoring is low which route is taken highly
depends on what is installed on the system: e.g. if if have an empty system
expect apache2 (=2.2.22-2) and co installed and I try upgrading I get the
situation you dislike.
Adding a package depending on apache2 and everything seems to be fine.
(in my apt testbench with mocks, but reality should be comparable)
But, I guess you want to hear a solution, right?
You will dislike it, but I don't see a way around transitional packages
apache2.2-bin --> apache2-bin
apache2.2-common --> apache2-data
and making all these unversioned Replaces+Conflicts into versioned
Replaces+Breaks just as §7.6.1 suggests.
(assuming they don't need to be Conflicts)
Everything else is just depending on luck in the end.
(aka: hoping that enough is installed to suggest the removal
of apache2.2-bin in favor of apache2-bin)
On the pro-side which I like to stress quiet a bit in these situations:
You don't confuse the user with a removal at dist-upgrade at least.
This way (s)he can latter remove the transitional packages to clean up
rather then worry what this means that apache2 packages are going to
be removed which is in my eyes the core problem of not having metadata
for it: We can't sensible tell the user the difference between
"just a rename" and "functionality will be removed"…
(and all the various gray shades in between which makes coming
up with metadata for it surprisingly difficult)
Best regards
David Kalnischkies
Reply to: