[Aptitude-devel] Bug#819943: really should add an unforbid-version command
Manuel A. Fernandez Montecelo
manuel.montezelo at gmail.com
Tue Apr 5 00:10:44 UTC 2016
Control: severity -1 wishlist
Control: tags -1 + wontfix
2016-04-04 03:05 積丹尼 Dan Jacobson:
>Today I will inspect the how hard it is to just simple reverse the action of
># aptitude forbid-version somepackage
>so we are back to the state before we did it.
>The man page says
> To revert the action, "aptitude install <package>" will remove the
> ban. To remove the forbidden version without installing the
> candidate version, the current version should be appended: "install
>Well I think you really should an unforbid-version command.
The documentation was improved after another recent request of yours
(duplicate, actually), #773023.
Forbid a package from being upgraded to a particular version, while
allowing automatic upgrades to future versions. This is useful for
example to avoid a known broken version of a package, without
having to set and clear manual holds.
By default, aptitude will select the forbidden version to be the
one which the package would normally be upgraded (the candidate
version). This may be overridden by appending “=<version>” to the
package name: for instance, “aptitude forbid-version
To revert the action, “aptitude install <package>” will remove the
ban. To remove the forbidden version without installing the
candidate version, the current version should be appended: “install
I think that it will explains quite clearly how to achieve what you
want, if you really want to undo "forbids".
>Also the man page should say if only one version can be forbidden or
It only mentions a single version that can be forbidden throughout the 3
paragraphs, and implies that forbidding several version is a job for
This seems to be sufficiently clear for mostly everybody, since there
are no duplicates about the issue in the last few years but yours.
>Also one thinks I could just use forbid-version=0 to clear it, but that
>is not a current version of that package.
># aptitude forbid-version package1 package2 package3 ... package20
>will require an enormous amount of work to reverse, digging up each
forbid-version is to mark a specific version of a package that you are
quite sure that you don't want to install, e.g. with a RC bug or a
problem that affects your systems badly.
Whenever a new version is available, the system will happily upgrade to
new versions, e.g. with dist-upgrade. So, as the doc explains quite
clearly, forbid-version is intended as a shortcut for "temporary holds"
on a specific version which self-destroy when a new version is available
and the sysadmin requires an upgrade of the system, a set of package or
a single package.
If you find that you're using forbid-version and need to revert it quite
often _without installing the new version of the packages already
available at the same time_, perhaps you would like to use only "hold"
(and its corresponding "unhold"), because the use that you are asking is
not what forbid-version is intended for and you are actually using it as
Blurring the lines even more between forbid-version and hold is IMO not
a very useful thing to do in general, and not cost-effective.
tl;dr: if you are not happy with the shorcut and semantics of "forbid",
just use the more general "hold".
>OK, let's try
># aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1
>We will very likely encounter some
>"The following actions will resolve these dependencies:
> Remove the following packages:"
>questions which we will very probably answer "n", never reaching the
>point where supposedly the forbid-version will be erased without
>installing the package before quitting!
>And, when you think about it
># aptitude install xserver-xorg-video-cirrus=<current-version>
>means the same as
># aptitude install xserver-xorg-video-cirrus
>so if one didn't want to install the package one would answer "n" when
>asked so never reaching the step where ... anyway one big no-op and the
It works exactly as intended... install will attempt to install a new
If you don't want to install a new version after all, having a "forbid"
on a version that you don't want installed _yet_ is harmless; so you
don't need to remove the "forbid" until/unless you are sure that you
want to install that version. Catch-22.
That there are conflicts when installing a version of a package, which
in turn cause the packages to be suggested to be removed or other
actions (a bunch of them upgraded at the same time, for example) is
completely orthogonal to the question at hand.
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>
More information about the Aptitude-devel