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

[Manuel A. Fernandez Montecelo]

2015-11-13 2:10 GMT+00:00 Vincent Lefevre <vincent at vinc17.net>:
> On 2015-11-12 21:57:33 +0000, Manuel A. Fernandez Montecelo wrote:
>> 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?
>
> No, when a package is on hold, aptitude does not give any notice
> when a new version arrives. That's why I don't like it.

So when you put packages on hold in testing, say "v1", and "v2"
appears in unstable or testing, the packages don't appear in the bunch
of "Upgradable" when there are newer versions?


>> 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.
>
> To know whether I am satisfied with some version, I need to know
> whether there is a new version. Otherwise the package remains on
> hold forever.

Apart from appearing in "Upgradable", one can limit the view to
"~U~ahold" (which is like upgradable but further limiting to only
packages on hold; if the list of Upgradable is too long to check all),
or one can check every now and then if the packages on hold have new
versions in their package info screen (hopefully you don't have dozens
of packages forbidden/hold).

If one feels that Hold is too heavy handed and that forbidding a
versions is a hassle because other versions appear all the time, one
can simply not upgrade the package until it's good to upgrade.  This
is mosly what I do.  They keep in the Upgradable set, so it's easy to
keep track of them.

It requires manual actions, but the proposed solutions also does
require manual actions, to forbid versions again and again as they
appear in repositories like unstable, if one is unsatisfied with many
versions and want to forbid them all of the time.  Checking whether
they continue to be broken or not (reading BTS, changelogs, whatever)
takes probably a bigger portion of time, though.


>> 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.
>
> But one can miss security fixes, which is really bad.

It can, because there are many ways in which mixing different suites
in your system and how you pin them can have undesired effects.

Forbidding versions will cause the same or equivalent sets of
problems, in the packages themselves and their reverse-depends.  In
fact, installing packages (without holding or forbidding at all) from
experimental or from backports can also make you miss security fixes
as well.

For example, if somebody uploads "package-v2~rc1" to experimental and
you install it, while versions v1 with fixes continue to arrive to
unstable, you miss all of those (unless you keep checking for them and
downgrade if necessary).  Same with stable/security if you use
packages backported with higher versions, or packages from testing or
unstable.  In particular, experimental can have broken packages for
years without anybody bothering to remove those.

All of these cases mostly happen if you upgrade to a version in
testing/unstable/backports while using stable, or experimental if
using unstable, because the security updates or more stable version
arrives in the suite with lower versions, so getting the newest fixes
implies checking by hand if new but "older/lower" versions arrive, and
downgrading.

All of this is in the terrain of "unsupported" and "you are on your
own", though.  Downgrading is something that you've been declaring as
quite dangerous in other bug reports, and it is true that it's
dangerous sometimes, so this should be taken into account before
mixing suites and versions from different suites.

Packaging tools will never know which repositories (esp. outside
Debian) are supposed to contain the best up to date or higher priority
for security upgrades, except in the sanctioned combinations to that
effect (stable+security, for example), so the user should better know
what s/he's up to when using unsupported suites.


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