[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:
>Package: aptitude
>Version: 0.7.8-1
>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
>           <package>=<version>".
>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
>version number...

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
a "hold".

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
>forbid-version stays.

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 mailing list