Control: severity -1 wishlist
Control: tags -1 + wontfix
Hi,
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-version
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
vim=1.2.3.broken-4”.
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>”.
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
more.
It only mentions a single version that can be forbidden throughout the 3
paragraphs, and implies that forbidding several version is a job for
"hold".
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.
And
# 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
version.
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.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
