[Aptitude-devel] Bug#663134: aptitude: safe-upgrade fails on libgcc1 version skew

[Sven Joachim]

On 2012-03-10 04:17 +0100, Daniel Hartwig wrote:

> On 10 March 2012 00:42, Sven Joachim <svenjoac at gmx.de> wrote:
>> Would be
>> interesting to see what apt-get does if the dist-upgrade does not
>> require removing essential packages.
>
> I have included output from apt-get in this situation.[1]
>
> It seems that both programs do the same thing here:
>
> 1. mark all upgradable packages
> 2. use the resolver to fix (i.e. not upgrade) packages causing breakage
>
> There is no special handling in apt-get; the implicit Breaks: for
> multi-arch packages does the job fine.
>
> However, the output of the programs does differ.  Aptitude
> safe-upgrade reports that it can not resolve the dependency problems
> (correct), and that the user should try using the full resolver (which
> would remove at least one of the packages; this is a useful option for
> a user)

Note that this affects unrelated upgradable packages, since "aptitude
safe-upgrade" does not find a solution, while the full resolver will
upgrade them.

> 'apt-get safe-upgrade' does not report that it found no way to resolve
> the dependencies, instead, it just outputs the usual "0 installed, 0
> upgraded…"

Right, if there are other upgradable packages, "apt-get upgrade" would
have upgraded them.

> dist-upgrade between the two programs is basically identical, trying
> to install one of the packages by removing the other (where possible).
>  Also, manually requesting to install the new version of the package
> is attemped by both programs, again by removing the other package
> where possible.
>
> I see two options here:
>
> 1. Continue to have safe-upgrade behave like apt-get upgrade; perhaps
> adjust the output of aptitude to include the "0 installed, … N not
> upgraded" status line at the end in the case of a nop.

This is desirable, I think, but you cannot really "continue" to behave
like "apt-get upgrade" because aptitude currently does not behave so.

> 2. Insert some logic to not mark packages violating the multiarch
> lockstep requirement, thereby avoiding invoking the resolver and the
> resulting status messages.
>
> Option 2 is easy, but personally I'd like to avoid it because it is an
> extra layer on top of the native APT implementation of the multiarch
> spec (i.e. implicit Breaks: self on these packages).  Also, aptitude's
> behaviour would internally deviate from apt-get's even though the
> results would appear similar.

There is also the theoretical possibility that the requirement to
upgrade "M-A:same" packages in lockstep might be lifted some day
(Guillem proposed this, but was apparently convinced/persuaded not to do
this). 

> Note that apt-get *does* consider the packages upgradable, but does
> not 'upgrade' them due to the implicit Breaks.  So I think here also
> the output of "aptitude search ~U" is ok, because the package is
> upgradable if the breakages are resolved.

This output is indeed entirely correct.

Cheers,
       Sven