[Aptitude-devel] Bug#642030: aptitude: cannot forbid more than 1 version of a package

[Vincent Lefevre]

On 2015-11-12 14:24:10 +0000, Manuel A. Fernandez Montecelo wrote:
> In the general case, if one is using v9-1 from unstable, v9-2 appears
> in unstable and v8-2 appears in testing and aptitude allows to forbid
> both, until it is actually released, one still doesn't know if the
> problem is going to be fixed in v8-3 and v9-3 (or any other future
> version that could pop up in the repositories at any point), so one
> has to keep constantly forbidding versions as they appear.

The problem is more the following: One has v1 installed. Then v2
appears in unstable and is buggy. One does "F" on it. Then v2 moves
to testing. Later, v3 appears in unstable and is still buggy. One
does "F" on it. But now, aptitude wants to install v2 from testing!

> If aptitude ignores forbidden versions "smaller" than a given version
> number, as you request, there are other sets of problems.
> 
> Similar to the example above, if one uses v8-1 from testing, v9-2
> appears in unstable with a problem and forbids that one, and then v8-2
> appears fixing an important data corruption problem, that version
> would be ignored potentially for months, until >v9-2 appears in one of
> the used repositories.

OK, but this problem exists in the current aptitude versions:
aptitude just shows v9-2. The only way to see v8-2 is to use "F",
ask for an upgrade, and the user will see v8-2 only if it can be
installed (i.e. it isn't blocked by a dependency or a conflict).

> Considering other suites and not only testing and unstable, there
> could be v9-2+exp1 appearing soon, not fixing the issue that concerns
> the person but with other dangerous/disruptive changes that it is
> offered (e.g. depending on a broken version of libimportant), and
> v9.2~backport1 could actually fixes the issue and one would like to
> install (but ~backport1 makes it to be "smaller" than the given
> version, so it would not show).

Ditto, aptitude only shows the latest version, so that only v9-2+exp1
is visible.

> If one uses testing+unstable things usually go forward, but there are
> still oddities as this case that you mention.  But there are also many
> other users of stable, backports and testing (or security upgrades),
> and probably more people using stable+backports+testing that people
> using testing+unstable, so hiding older versions is not such a good
> idea in those scenarios.

"F" does not hide older versions. They are already hidden by default.

> tl;dr: relying on which version number is higher to presuppose things
> is not very foolproof, especially if one mixes versions and uses
> suites in flux like testing and unstable.
> 
> On the other hand, one can use Hold, and Unholding only after one
> verifies that a new version was released and is OK to install.

But with Hold, one cannot see when a new version is available.

> There are multiple ways to verify if new versions were released --
> curses interface,

No, this is not visible with the curses interface.

> command line patterns,

?

> paying attention to the number of not upgraded packages in the
> command line mode (does not work if one holds package almost all of
> the time, but still),

We, I only use the curses interface.

> or passing "-v" in future releases (see #553577) to list the number
> of packages that are not upgraded, in command line operations.

Same problem.

> Independently of that, I think that change the behaviour of this long
> stablished feature that can potentially hide security or backports is
> not good, and blurring more the lines between forbid-version and hold
> is not good design, and that's presumably why this hasn't been
> implemented by previous developers, so marking it as +wontfix.

So, perhaps a solution would be to be able to have really several
forbidden versions in /var/lib/aptitude/pkgstates: if a user forbids
v2, them forbids v3 when it appears, then v2 should still be marked
as a forbidden version.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)