[Aptitude-devel] Bug#452589: aptitude: really hold packages

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Sat Nov 14 01:29:33 UTC 2015

Control: tags -1 - confirmed + wontfix

2012-09-14 12:15 Daniel Hartwig:
>Control: retitle -1 aptitude: [curses] actions on package sets should respect holds
>Control: tags -1 confirmed
>The reasoning here is that holds, etc. should be respected unless a user
>performs an action specifically on a given package.  That is, given this
>   --\ Upgradable Packages (553)
>A    --\ admin (40)
>       --\ main (40)
>   i     adduser                             3.113+nmu1     3.113+nmu3
>   i     at                                  3.1.13-1       3.1.13-2
>B  ih    base-files                          6.7            6.11
>performing an install on line A should not cause the package base-files
>to be upgraded since it is marked as held.  Performing an install on
>line B *should* cause that package to be upgraded.
>It makes sense to have this behaviour configurable.  In any given
>circumstance it may or may not be the users intention to respect holds.
>For actions on package sets, setting FromUser=false when calling
>MarkInstall would achieve this.  When installing packages that will have
>the side effect of also marking them auto-installed.  This will need to
>be managed to prevent that happening.

I do not think that the current behaviour existing for years should be
changed lightly.

If this is changed for Holds, probably should be changed at least for
Forbid-version as well, and a whole bunch of documentation changed

In general, this would add an inconsistency in the handling of applying
actions for whole groups, and maybe this should be revisited for others
as well.  For example, should "keep" (":") reset Holds in that case?  It
resets Holds in the individual case, so if there is a whole group with
only (or many/mostly) Hold packages, perhaps the user expects to do this
as the only way to unhold a package in curses (without going one by
one).  Should Hold itself be allowed to be applied to groups, if Unhold
is not allowed?  And so on.

Configuration, as the last e-mails says, would solve some of these
concerns.  But adding configuration options is also to not to be done
lightly, once added it never goes away -- and we already have a huge
amount of those, and a very complex configuration at that (complexity of
the fields, mix/interferences with apt options, etc).

As an alternative solution, one can temporarily limit the screen with
"!~ahold", so the package view ignores packages on hold while the
actions are performed on the groups.  I think that this is a simple,
quick and elegant solution to this problem.

In any case, after 8 years since the original request and 3 since the
last message, I think that it's fairly clear to conclude that this is
not going to be addressed in the near future, so leaving open but
marking as +wontfix for the time being.

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

More information about the Aptitude-devel mailing list