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

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Fri Nov 13 12:07:18 UTC 2015

2015-11-13 11:31 GMT+00:00 Vincent Lefevre <vincent at vinc17.net>:
> On 2015-11-13 10:59:01 +0000, Manuel A. Fernandez Montecelo wrote:
>> 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?
> They still appear on hold, and I cannot know whether there is a new
> version or not.
> [...]

Assuming that the version is not the "candidate version" already
visible in the right-most column (which in many/most examples given so
far, it should be), I can only suggest manual review by looking into
the package info screen.

>> 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.
> I use neither experimental[*] nor backports. I don't use unofficial
> repositories like Debian multimedia either.
> [*] Well, only in some exceptional cases to test bug fixes, but then
> I track what happens.

Testing and unstable are also for people who are OK with getting their
hands dirty and track what happens when it is needed to, more so when
mixing versions of both.  The recent turmoil with the GCC-5 transition
is a recent enough proof of that.

When packages are on hold/forbidden/not upgraded it is also an unusual
condition, so you have to keep track of what happens.

Simply having the packages already in the Upgradable set or on Hold
(or Forbid) is a highlight and constant reminder that you have to keep
track of them to bring them out of that state.

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

More information about the Aptitude-devel mailing list