Bug#452589: aptitude: really hold packages
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 ihbase-files 6.76.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
Bug#452589: aptitude: really hold packages
Michal has explained in private email that what he wants is for '+' to be a no-op on held packages (and presumably also '-' and '_'). This is an interesting idea but also a radical departure from how aptitude has traditionally behaved. It will require some thought. (if, as is likely, I don't reply to this for a long time, it means something with a higher priority got my attention and someone should ping me) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452589: aptitude: really hold packages
On Nov 24, 2007, at 6:57 AM, Daniel Burrows wrote: On Fri, Nov 23, 2007 at 09:48:40PM +0100, Michal Suchanek [EMAIL PROTECTED] was heard to say: When I use h in the curses interface to hold package in its current state aptitude still considers the package upgradeable. Thus if I hold for example my graphics driver because the new versions are broken I can no longer use u on the X11 folder in the tree view because it marks the graphics driver for upgrade as well. The hold flag should really hold the package in its current state as described in the help until un-held. If I set packages to a hold state, they seem to be held properly. Perhaps there are some packages that depend on newer versions of the packages that you have held? Daniel The scenario I am talking about; 1) hold xorg-video-ati (or whatevet it is called right now) 2) close aptitude 3) open aptitude, open the upgradable packages subtree, locate the (still closed) X11 subtree 4) press u on the X11 subtree result: the video driver is marked for upgrade if I manually find it and say it should be left as is there is no dependency problem expected: the driver is left as is. If I marked the package to be held in current state it is because I do not want it upgraded. Thanks Michal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452589: aptitude: really hold packages
On Wed, Nov 28, 2007 at 02:56:44PM +0100, Michal Suchanek [EMAIL PROTECTED] was heard to say: On Nov 24, 2007, at 6:57 AM, Daniel Burrows wrote: If I set packages to a hold state, they seem to be held properly. Perhaps there are some packages that depend on newer versions of the packages that you have held? Daniel The scenario I am talking about; 1) hold xorg-video-ati (or whatevet it is called right now) 2) close aptitude 3) open aptitude, open the upgradable packages subtree, locate the (still closed) X11 subtree 4) press u on the X11 subtree result: the video driver is marked for upgrade if I manually find it and say it should be left as is there is no dependency problem expected: the driver is left as is. If I marked the package to be held in current state it is because I do not want it upgraded. Could you run aptitude-create-state-bundle and send me the file it produces? That might help me understand what's going on. Thanks, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452589: aptitude: really hold packages
Package: aptitude Version: 0.4.6.1-1.1 Severity: normal When I use h in the curses interface to hold package in its current state aptitude still considers the package upgradeable. Thus if I hold for example my graphics driver because the new versions are broken I can no longer use u on the X11 folder in the tree view because it marks the graphics driver for upgrade as well. The hold flag should really hold the package in its current state as described in the help until un-held. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23.3-src (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.6-6 0.7.6 Advanced front-end for dpkg ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libgcc1 1:4.2.2-3 GCC support library ii libncursesw5 5.6+20071013-1 Shared libraries for terminal hand ii libsigc++-2.0-0c2a2.0.17-2 type-safe Signal Framework for C++ ii libstdc++64.2.2-3The GNU Standard C++ Library v3 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do none (no description available) pn libparse-debianchangelog-perl none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452589: aptitude: really hold packages
On Fri, Nov 23, 2007 at 09:48:40PM +0100, Michal Suchanek [EMAIL PROTECTED] was heard to say: When I use h in the curses interface to hold package in its current state aptitude still considers the package upgradeable. Thus if I hold for example my graphics driver because the new versions are broken I can no longer use u on the X11 folder in the tree view because it marks the graphics driver for upgrade as well. The hold flag should really hold the package in its current state as described in the help until un-held. If I set packages to a hold state, they seem to be held properly. Perhaps there are some packages that depend on newer versions of the packages that you have held? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
