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

Thu Nov 12 21:57:33 UTC 2015

2015-11-12 15:49 GMT+00:00 Vincent Lefevre <vincent at vinc17.net>:
> 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!

My example was bad, all versions in testing come through unstable
first anyway, so there should be no cases like the above.

My example would work better if we consider unstable+experimental, or
stable+security+backports + testing (for the occasional package), the
packages can "arrive" independently with different versions in
different suites.

If forbidding versions ignores all versions prior to the one ignored,
forbidding the one in experimental (first case) or testing (second
case) will make aptitude ignore all new versions arriving in unstable
(first case) or stable+security+backports, which is the side-effect
that I don't like, compared to the current implementation.

The hypotetical implementation of F-ignoring-older-than would behave
exactly the same as "put the package on hold but remove it once a
package with version >VV arrives".  That's equivalent to "hold"
(except the manual re-enablement), and that's why I was suggesting it
as an alternative solution to the original report.

In your example above, using hold also would not install v2 from
testing, and when v4 appears, you notice and unhold, and all is well.
What's the drawback of using Hold in your use-case?

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

My bad.  With "visible" I meant mostly "aptitude takes it into account
for resolving", it shows in dependency resolutions and so on.

For example, I had forbidden the versions of LibreOffice in
experimental, and the resolver still allows me to upgrade to the newer
versions of LibreOffice in unstable when they arrive (the packages
show up in "Upgradable", and the version arriving in unstable is
shown).

With the behaviour that you propose, it would be exactly like Hold,
and if I forbid LibreOffice with a higher version in experimental I
would not be able to upgrade to the newer version of LibreOffice in
unstable, and I might have to withhold upgrading other packages
because of this.  With the current implementation of F, this is
possible, and it is an important use case.

So if we change the current implementation of F for the new, we would
lose important use cases explained before, while gaining basically
nothing, in my view.

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

Nope, it shows the candidate version in the right-most column (e.g.
the latest in unstable instead of the most recent in experimental,
unless experimental is pinned higher).

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

With the provision of "hiding" == "ignoring for all practical
purposes", in the 3 examples above, F (with "ignore older than") and H
would behave in the same way (except the automatic unhold) and would
ignore ("hide") all older version, while the current implementation of
F does only ignore a specific version.

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

The candidate version (not the highest, but the candidate; e.g. the
latest in unstable instead of the one in experimental) is shown in the
right-most columns.  Once it reaches a version that you are satisfied
with, you unhold and it will be allowed to install.

>> There are multiple ways to verify if new versions were released --
>> curses interface,
>
> No, this is not visible with the curses interface.

It does: when there are newer *candidate* versions it shows in the
list of packages as "upgradable", it shows the candidate version in
the right-most column (as I explained above), and all the versions are
listed in the package info screen.

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

If one considers the bigger picture, forbidding versions or marking on
hold should be exceptional measures, not something that one does all
of the time.

If there is only one bad version that is known to misbehave, OK, one
forbids that.

If there are multiple versions that one wants to forbid, then there is
something seriously wrong with the package (or something needed by the
current versions that other versions don't provide), so one might as
well use Hold until the situation clears up.  It is almost equivalent
to forbid-version with multiple versions, and has no serious drawbacks
(except the need for manual Unhold), and if the current "safe" package
stays in the system a bit longer than strictly necessary (because the
user does not notice that it's in the "Upgradable" packages), there is
no big harm.

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