[Aptitude-devel] Bug#795228: aptitude: upgraded a package to experimental without notice

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi,

2015-08-12 01:46 Vincent Lefevre:
>Package: aptitude
>Version: 0.6.11-1+b1
>Severity: important
>
>Yesterday, during an upgrade of my Debian/unstable machine with
>aptitude via its UI (with the new libstdc++6 in particular),
>aptitude upgraded a package (powertop) from unstable to experimental
>(see aptitude log in attachment), and I wasn't aware of this until
>now. On another machine, I can see that by default, packages are not
>upgraded to experimental.
>
>For instance, on another machine (with blocked packages),
>"aptitude install apt" refuse to upgrade apt (ditto via its UI),
>while "aptitude install -t experimental apt" proposes to upgrade it.
>
>openntpd 1:5.7p4-1 was the only experimental package I installed
>manually (with "apt-get install openntpd/experimental", IIRC).
>
>For the aptitude configuration, I have:
>
>Aptitude::ProblemResolver::SolutionCost "removals";

(in the attachment)

>...
>[UPGRADE] libstdc++6:amd64 5.1.1-14 -> 5.2.1-15
>...
>[UPGRADE] powertop:amd64 2.6.1-1 -> 2.7-1~exp1
>...

libstdc++6 added breaks on "powertop (<= 2.6.1-1)", still present today.

This was for the big transition and change in ABI that happened a few
days before the report, on the 1st of August, for the big GCC-5 / C++11
ABI transition.

Probably the libstdc++6 maintainer didn't realise that a version of
powertop was present in experimental, or didn't consider the option to
add breaks to versions in experimental in general (the transition was
taxing enough for everybody, and on him specially), but actually it
should have added breaks this version too.

In that case, you wouldn't have been able to upgrade libstdc++6 while
powertop was not recompiled against it with a binNMU (and 2.8 was
uploaded at some point in september), or powertop would have to be
removed.

With the SolutionCost of "removals", aptitude doesn't take into account
installing by priorities or non-default releases, it just tries to
minimise the removals, so seing that it could solve the problem by
upgrading to 2.7-1~exp1, it just did that.


In the preview window of the curses interface it shows the candidate
version to be installed (2.7-1~exp1), and in the solution resolver in
curses (that transition in particular used to cause many conflicts) and
the command line shows something similar to [1], including version and
suite.  The "upgrade" in the command line is a bit more silent, one can
show versions with --show-versions.

With patterns in the command line one can select whether to upgrade only
packages with a given priority, or not from archive experimental, for
example.


[1]
      Upgrade the following packages:
...
35)     libblkid1 [2.27.1-3 (now) -> 2.27.1-6 (unstable)]


-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>