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

[Daniel Hartwig]

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)

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

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

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.


Let me know your thoughts.


Regards


[1] apt-get upgrade, dist-upgrade; aptitude full-upgrade

# apt-cache policy lockstep-bad lockstep-bad:armel
lockstep-bad:
  Installed: 1.0
  Candidate: 1.0
  Version table:
 *** 1.0 0
        500 file:/home/daniel/repo/multiarch-no-lockstep/rep-lockstep/
binary-powerpc/ Packages
        100 /home/daniel/repo/multiarch-no-lockstep//var/lib/dpkg/status
lockstep-bad:armel:
  Installed: 1.0
  Candidate: 2.0
  Version table:
     2.0 0
        500 file:/home/daniel/repo/multiarch-no-lockstep/rep-lockstep/
binary-armel/ Packages
 *** 1.0 0
        100 /home/daniel/repo/multiarch-no-lockstep//var/lib/dpkg/status
# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  lockstep-bad:armel
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  lockstep-bad
The following packages will be upgraded:
  lockstep-bad:armel
1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
E: The package index files are corrupted. No Filename: field for
package lockstep-bad.

# ./aptitude dist-upgrade
The following packages will be upgraded:
  lockstep-bad:armel{b}
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
The following packages have unmet dependencies:
 lockstep-bad : Breaks: lockstep-bad:armel (!= 1.0) but 2.0 is to be installed.
 lockstep-bad:armel : Breaks: lockstep-bad (!= 2.0) but 1.0 is installed.
E: The package index files are corrupted. No Filename: field for
package lockstep-bad.
The following actions will resolve these dependencies:

     Remove the following packages:
1)     lockstep-bad:armel



Accept this solution? [Y/n/q/?] n

The following actions will resolve these dependencies:

     Remove the following packages:
1)     lockstep-bad



Accept this solution? [Y/n/q/?] q
Abandoning all efforts to resolve these dependencies.
Abort.