Re: Need help sorting out apt-get behavior during upgrade

[Stefan Fritsch <sf@sfritsch.de>]

Hi David,

thanks for your response.

On Wednesday 28 March 2012, David Kalnischkies wrote:
> > 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.

There is no indication in the policy that 7.6.2 does not apply to 
upgrades. The first paragraph in 7.6.2 does not talk about Provides at 
all. The second paragraph says "can be a virtual package", so the 
Provides is clearly optional.

> 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…

If a package conflicts+replaces its own package name,  or with a 
virtual package it provides, this is a special situation described in 
7.4. But the case we have here, where one package conflicts+replaces 
the other, but NOT the other way round, is clearly different. 

> 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)

The policy says otherwise ("`Replaces' allows the packaging system to 
resolve which package should be removed when there is a conflict"). If 
the policy is wrong, you should get it changed, but I think this is a 
bug (or missing feature) in apt.

Or do you see any reason not to treat a one-way conflicts+replaces as 
a package rename?

> 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)

apache2.2-common is the package that is depended upon for the apache 
2.2 module ABI. Making it a transitional package is not an option, 
IMHO. It would need to have versioned Breaks against around 100 module 
packages.

An apache2.2-bin transitional package is possible, though. But if I 
understand you correctly, having only one of the two transitional 
packages wouldn't give 100% certainty that the upgrade works? In that 
case we will need an entry in the release notes.

Cheers,
Stefan