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

[Manuel A. Fernandez Montecelo]

severity 642030 wishlist
tags 642030 + wontfix
stop


2015-11-12 13:37 GMT+00:00 Vincent Lefevre <vincent at vinc17.net>:
> Control: reopen -1
>
> On 2015-11-12 11:59:15 +0000, Manuel A. Fernandez Montecelo wrote:
>> Even if this worked for multiple versions, if you are unsure in which
>> version the package is going to fix a problem,
>
> I am sure concerning which version*s* to forbid.
>
>> it is more practical to use the Hold feature until you verify that
>> it is fixed and safe to install, rather than to keep adding F
>> versions every time that a new version pops up in the repositories
>> (or failing to do so and be installed to a version that you don't
>> want).
>
> I want to be able to upgrade to future versions (actually be aware
> of them, which is what "F" does). So, "Hold" is not OK here.
>
> Remember that users can track both testing and unstable, and aptitude
> does not always try to install the latest version. The problem I had
> is that when I did "F" on the unstable version, aptitude then wanted
> to upgrade to the testing version (i.e. en earlier version), which is
> wrong.

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.

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.

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

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.

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.  If the
package that it's on hold is safe to use, keeping in the system even
when there are upgrades around, is no a big problem.

There are multiple ways to verify if new versions were released --
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), or
passing "-v" in future releases (see #553577) to list the number of
packages that are not upgraded, in command line operations.


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.


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