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
situation:
--\ 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
everywhere.
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.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
