Bug#576319: aptitude: "Cancel pending actions" erase "h - hold" state

[Osamu Aoki]

Package: aptitude
Version: 0.6.1.5-3
Severity: normal

I am not C++ coder but src/cmdline/cmdline_do_action.cc line 299 is where
problem comes from.

Please read on.

When I set a lower priority version in hold using =, I expect that
settig to live future package install actions unless specifically requested to
be removed. Aptitude menu suggest so.

"=": Hold a package in its current version to prevent upgrades.
":": Keep a package at its current version. Unlike hold, this
will not prevent future upgrades.

But "Actions" -> "Cancel pending actions" reset this frag too. (The same goes to
keep-all for command line. It resets "State: installed [held]" to "State: installed".)

This menu entry is frequently used to revert suggested "dependencies" upon
starting interactive session or "aptitude install".

The logic to should be exactly as keep-all documented:

Cancels all scheduled actions on all packages; any packages whose sticky
state indicates an installation, removal, or upgrade will have this sticky
state cleared.

So it should clear sticky state only if sticky state is not set to "hold (=)"
like flag. This is important since this situation is quite annoying and makes
"hold (=)" comletely useless.

I tracked down to src/cmdline/cmdline_do_action.cc . There:

----------
// If keep-all is the argument, we expect no patterns and keep all
// packages back.
if(!strcasecmp(argv[0], "keep-all"))
{
if(argc != 1)
{
cerr << _("Unexpected pattern argument following \"keep-all\"") << endl;
return -1;
}

for(pkgCache::PkgIterator i=(*apt_cache_file)->PkgBegin();
!i.end(); ++i)
(*apt_cache_file)->mark_keep(i, false, false, NULL);
}
----------

This seems to unconditonally reset mark_keep. From cmdline_action.cc, this
data structure is about hold etc.

case cmdline_hold:
(*apt_cache_file)->mark_keep(pkg, false, true, NULL);

So it seems adding some check of current state before zapping state to (i, false, false, NULL).

I am not C++ coder so I will not make patch but cmdline_do_action.cc line 299 is where problem comes from.

Also, as I checked, User help screen has following

The "action" flag is one of the following:

h - hold
p - purge
d - delete (remove)
B - broken
i - install
r - reinstall
u - upgrade
F - the available upgrade has been forbidden via "F"

I do not know if we also have to check for "F" and "r". "F" seems to be option
set by user which is expected to live long if not specifically requested, I say
it should not be reset by keep-all.

"r" seems to be the same as hold by ":", they could be skipped by keep-all too. (I
should say, I do not care too much on this.)

So, please consider these points when fixing this bug. Also updating
documentation to note on hold etc. should help user.

Osamu

FYI:

I was winderting why my "h - hold" (set by =) is getting killed sometime after
when I do some package install with a combination aptitud recommended as the
first choice. I think I finally tracked down where this strange thing was
happening.

-- Package-specific info:
aptitude 0.6.1.5 compiled at Mar 12 2010 18:48:34
Compiler: g++ 4.4.3
Compiled against:
apt version 4.8.0
NCurses version 5.7
libsigc++ version: 2.2.4.2
Ept support enabled.
Gtk+ support disabled.

Current library versions:
NCurses version: ncurses 5.7.20100313
cwidget version: 0.5.16
Apt version: 4.8.0
linux-vdso.so.1 => (0x00007fff771ff000)
libapt-pkg-libc6.9-6.so.4.8 => /usr/lib/libapt-pkg-libc6.9-6.so.4.8 (0x00007f44256a8000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007f4425455000)
liblog4cxx.so.10 => /usr/lib/liblog4cxx.so.10 (0x00007f4425067000)
libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x00007f4424e62000)
libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0x00007f4424b96000)
libept.so.0 => /usr/lib/libept.so.0 (0x00007f442491e000)
libxapian.so.15 => /usr/lib/libxapian.so.15 (0x00007f44245cd000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f44243b6000)
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007f4424125000)
libboost_iostreams.so.1.40.0 => /usr/lib/libboost_iostreams.so.1.40.0 (0x00007f4423f1a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f4423cfe000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f44239e9000)
libm.so.6 => /lib/libm.so.6 (0x00007f4423767000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f4423551000)
libc.so.6 => /lib/libc.so.6 (0x00007f44231fc000)
libutil.so.1 => /lib/libutil.so.1 (0x00007f4422ff9000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f4422df5000)
libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x00007f4422bd1000)
libdb-4.8.so => /usr/lib/libdb-4.8.so (0x00007f4422857000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007f442261f000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007f442240e000)
librt.so.1 => /lib/librt.so.1 (0x00007f4422206000)
/lib64/ld-linux-x86-64.so.2 (0x00007f442598c000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007f4422001000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f4421dca000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f4421ba2000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores)
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.9 0.7.25.3 Advanced front-end for dpkg
ii libboost-iostreams1.40. 1.40.0-6+b1 Boost.Iostreams Library
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii libcwidget3 0.5.16-3 high-level terminal interface libr
ii libept0 0.5.30 High-level library for managing De
ii libgcc1 1:4.4.3-5 GCC support library
ii liblog4cxx10 0.10.0-1.1 A logging library for C++
ii libncursesw5 5.7+20100313-1 shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.2.4.2-1 type-safe Signal Framework for C++
ii libsqlite3-0 3.6.23-1 SQLite 3 shared library
ii libstdc++6 4.4.3-5 The GNU Standard C++ Library v3
ii libxapian15 1.0.18-1 Search engine library
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages aptitude recommends:
ii apt-xapian-index 0.26 maintenance tools for a Xapian ind
ii aptitude-doc-en [aptitude-doc 0.6.1.5-3 English manual for aptitude, a ter
ii aptitude-doc-ja [aptitude-doc 0.6.1.5-3 Japanese manual for aptitude, a te
ii libparse-debianchangelog-perl 1.1.1-2 parse Debian changelogs and output
ii sensible-utils 0.0.2 Utilities for sensible alternative

Versions of packages aptitude suggests:
ii debtags 1.7.9+b2 Enables support for package tags
ii tasksel 2.81 Tool for selecting tasks for insta

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


2010-04-03 04:09 Osamu Aoki:

>Package: aptitude
>Version: 0.6.1.5-3
>Severity: normal
>
>I am not C++ coder but src/cmdline/cmdline_do_action.cc line 299 is where
>problem comes from.
>
>Please read on.
>
>When I set a lower priority version in hold using =, I expect that
>settig to live future package install actions unless specifically requested to
>be removed. Aptitude menu suggest so.
>
> "=": Hold a package in its current version to prevent upgrades.
> ":": Keep a package at its current version. Unlike hold, this
> will not prevent future upgrades.
>
>But "Actions" -> "Cancel pending actions" reset this frag too. (The same goes to
>keep-all for command line. It resets "State: installed [held]" to "State: installed".)
>
>This menu entry is frequently used to revert suggested "dependencies" upon
>starting interactive session or "aptitude install".

Note that the help that appears in the bottom of the screen when you
"hover" over that option in the menu is:

"Cancel all pending installations, removals, holds, and upgrades."

I do not have a strong preference, and there is some sense in what you
say, but it seems that this has been done on purpose and by design.

(As a data point, I almost never used this option, BTW).


One thing to take into account is that in the command line there are
ways to mass-apply changes to packages (combinations of hold, unhold,
keep and keep-all, with patterns). One can easily apply "keep" (==
reset pending install/upgrade/removal state) to packages which are not
already on hold, for example, so avoiding to change the flag of those
packages.

But in the UI, I think that there would be no way to reset the hold
state of all packages on hold, without going one by one and resorting to
the command line.

So if we simply change the menu option without offering alternatives,
maybe some users which already rely on this functionality are not happy.


There are many angles to consider to this question, so it will require
some thought, and review many other bug reports that have requests about
holds first.


Cheers.
--
Manuel A. Fernandez Montecelo <manuel.m...@gmail.com>

[Axel Beckert]

Control: tag -1 + confirmed

Hi,

(I've used moreinfo + confirmed on purpose as I consider this to
indeed be an issue, but it's still unclear how to solve it.)

Manuel A. Fernandez Montecelo wrote:
> >When I set a lower priority version in hold using =, I expect that
> >settig to live future package install actions unless specifically requested to
> >be removed. Aptitude menu suggest so.
> >
> > "=": Hold a package in its current version to prevent upgrades.
> > ":": Keep a package at its current version. Unlike hold, this
> > will not prevent future upgrades.
> >
> >But "Actions" -> "Cancel pending actions" reset this frag too. (The same goes to
> >keep-all for command line. It resets "State: installed [held]" to "State: installed".)
> >
> >This menu entry is frequently used to revert suggested "dependencies" upon
> >starting interactive session or "aptitude install".
>
> Note that the help that appears in the bottom of the screen when you
> "hover" over that option in the menu is:
>
> "Cancel all pending installations, removals, holds, and upgrades."
>
> I do not have a strong preference, and there is some sense in what you
> say, but it seems that this has been done on purpose and by design.
>
> (As a data point, I almost never used this option, BTW).

I've been run into this multiple times, too, and I also wondered if
the current behaviour is really that helpful.

> One thing to take into account is that in the command line there are
> ways to mass-apply changes to packages (combinations of hold, unhold,
> keep and keep-all, with patterns). One can easily apply "keep" (==
> reset pending install/upgrade/removal state) to packages which are not
> already on hold, for example, so avoiding to change the flag of those
> packages.

Since hold is a stonger version of keep, I'd not reset it either.

> But in the UI, I think that there would be no way to reset the hold
> state of all packages on hold, without going one by one and resorting to
> the command line.
>
> So if we simply change the menu option without offering alternatives,
> maybe some users which already rely on this functionality are not happy.

Yep. I think, we should split it up:

keep -- reset all install/purge/delete/reinstall scheduled actions
reset -- reset all install/purge/delete/reinstall scheduled action plus hold

It's more difficult in the TUI, though:

Both options should of course show up in the menu.

For the keybindings, I'm indecisive:

My feeling says:

* ":" on a package should reset a "hold".
* ":" on a branch should not reset a "hold".
* This is inconsistent. ;-)

A possible keybinding for "reset" could be ";" (":" without Shift on
US keyboard layout, not yet used), but then again I think that key
combo should be even more harder to type than ":" and not be a single
key strike which can easily be hit unexpectedly.

Looking forward for further comments!

Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE

[Ralf Jung]

Hi,

Wow, finally I know what has been causing all that frustration over the
years! I have been hit time and time again by the problem that aptitude
kept forgetting which packages I had on hold. Recently, while the gcc5
transition was being staged and I had >100 packages on hold, that was
really annoying. When aptitude forgot (again) all the things I told it,
it took me minutes to get all the packages I wanted on hold back to that
state.

It never occurred to me that "Cancel pending updates" could reset the
hold state. Admittedly, I didn't read the description at the bottom, but
the menu entry is IMHO pretty clear: Having a package on hold is a
fairly permanent state, similar to the "automatically installed" bit. I
frequently use "Cancel pending actions" to get aptitude back into a sane
state, when it selected a strange set of updates or otherwise dragged
itself into some bad corner.

IMHO, having "Cancel pending updates" affect the hold bit is just as
surprising as if it would affect the "automatically installed" bit. I
expected it to act as if I would manually have selected "Keep" on every
single package. Now, I just noticed that "keep" also clears the hold
bit. I don't understand this, either: The description says "Cancel any
action on the package". But "hold" is not an action; it is a state -
just like "automatically installed" is. It means "please don't update
this package, ever", similar to how "automatically installed" means
"please uninstall this package when nobody depends on it anymore".
Again, why does "keep" reset one part of the state, but not the other?

The description shown at the bottom when selecting "Cancel pending
actions" gives it away, I admit that. It also says "Cancel pending ...
holds ....", which I don't know what it means. How can a hold be
"pending"? It's as if the hold was sitting there, waiting to be executed
at some point - that's what "pending" means, isn't it? But that's not at
all what hold is doing. So, overall, I have to say this is a *very*
confusing UI.

And finally, regarding the functionality that's lost when "Cancel
pending actions" no longer reset the hold bit: First of all, I have a
hard time imagining a situation where I would want to wholesale reset
the hold bit of all packages; similar to how the situation in which
you'd want to reset the "automatically installed" bit of every package
is IMHO rare. But that may be just my lack of imagination. In any case,
*if* a package ends up not being updated because it is on hold, that's
easily noticed because the "Upgradable packages" category will list
them. And finally, the aptitude search functionality can easily be used
to identify all packages that are on hold, and to reset that state.

Kind regards,
Ralf

[Manuel A. Fernandez Montecelo]

2015-09-25 12:11 Ralf Jung:

>Hi,
>
>Wow, finally I know what has been causing all that frustration over the
>years! I have been hit time and time again by the problem that aptitude
>kept forgetting which packages I had on hold. Recently, while the gcc5
>transition was being staged and I had >100 packages on hold, that was
>really annoying. When aptitude forgot (again) all the things I told it,
>it took me minutes to get all the packages I wanted on hold back to that
>state.
>
>It never occurred to me that "Cancel pending updates" could reset the
>hold state. Admittedly, I didn't read the description at the bottom, but
>the menu entry is IMHO pretty clear: Having a package on hold is a
>fairly permanent state, similar to the "automatically installed" bit. I
>frequently use "Cancel pending actions" to get aptitude back into a sane
>state, when it selected a strange set of updates or otherwise dragged
>itself into some bad corner.

It's funny how Axel, you and other people use that frequently; but I
almost never use it and always use Undo. Maybe it's because I usually
cherry-pick updates rather than wholesale, so I go step by step and
there Undo is more useful.

I think that it's usually usually safer to use Undo for the time being
even for wholesale operations, though.

>IMHO, having "Cancel pending updates" affect the hold bit is just as
>surprising as if it would affect the "automatically installed" bit. I
>expected it to act as if I would manually have selected "Keep" on every
>single package. Now, I just noticed that "keep" also clears the hold
>bit. I don't understand this, either: The description says "Cancel any
>action on the package". But "hold" is not an action; it is a state -
>just like "automatically installed" is. It means "please don't update
>this package, ever", similar to how "automatically installed" means
>"please uninstall this package when nobody depends on it anymore".
>Again, why does "keep" reset one part of the state, but not the other?

No idea. Knowing other cases in which surprising behaviour happened,
there usually is/was a good explanation for it, whether you agree with
the original developer or not.

>And finally, regarding the functionality that's lost when "Cancel
>pending actions" no longer reset the hold bit: First of all, I have a
>hard time imagining a situation where I would want to wholesale reset
>the hold bit of all packages; similar to how the situation in which
>you'd want to reset the "automatically installed" bit of every package
>is IMHO rare.

I can imagine a situation in which you use unstable, and have some
packages on hold scattered over many sections in the default view
(e.g. parts of KDE, GNOME or some other big collections of related
packages) because you are scared of the upgrade or it's half-broken for
weeks, and then you unhold them at once when you are ready to upgrade.

Or the same with stable and testing, perhaps testing with higher
priority but wanting to keep some subset of packages in unstable, and
then upgrading all of them together when a new release is out.

I don't think that it's a terribly popular use-case, but hey...

And I cannot imagine scenarios wanting to clear "automatically
installed" so easily, no.


So anyway, let's see. It looks like it's better to not touch holds when
clearing pending actions, but I don't know how difficult it is because
from fixing a few similar issues recently, sometimes the code is very
entangled and it takes days or more than a week to get to a proper fix,
even if in the end the changes amount a handful lines of lines changed,
or less.

[Manuel A. Fernandez Montecelo]

2015-09-20 15:11 Axel Beckert:

>> One thing to take into account is that in the command line there are
>> ways to mass-apply changes to packages (combinations of hold, unhold,
>> keep and keep-all, with patterns). One can easily apply "keep" (==
>> reset pending install/upgrade/removal state) to packages which are not
>> already on hold, for example, so avoiding to change the flag of those
>> packages.
>
>Since hold is a stonger version of keep, I'd not reset it either.

(Not because I agree with it, but I post this as further information
about the original intentions, and as a reminder that this sould also be
updated -- as well as the manual, quick help, etc).


I found that it is also documented in the manual, and says:

http://aptitude.alioth.debian.org/doc/en/ch02s01s02.html

Actions → Cancel pending actions

Cancel all pending installations, removals, upgrades, and holds. This
is equivalent to executing the Keep command on every package in the
package database.


http://aptitude.alioth.debian.org/doc/en/ch02s02s03.html#pkgCmdKeep


Keep: Package → Keep (:)

Flag the current package to be kept at its current version.

Any action that was to be performed on the package -- installation,
removal, or upgrade -- is cancelled, and any persistent hold that was
set on the package is removed.


Hold: Package → Hold (=)

Set a persistent hold on the package.

As with Keep, any action that was to be performed on the package is
cancelled. In addition, the package will not be automatically upgraded
[a] until the hold is removed. You may cancel a hold by issuing the
Install command.

(doesn't mention "Keep" or even "among other options" as a possible way
to cancel it)

>> But in the UI, I think that there would be no way to reset the hold
>> state of all packages on hold, without going one by one and resorting to
>> the command line.
>>
>> So if we simply change the menu option without offering alternatives,
>> maybe some users which already rely on this functionality are not happy.
>
>Yep. I think, we should split it up:
>
>keep -- reset all install/purge/delete/reinstall scheduled actions
>reset -- reset all install/purge/delete/reinstall scheduled action plus hold
>
>It's more difficult in the TUI, though:
>
>Both options should of course show up in the menu.
>
>For the keybindings, I'm indecisive:
>
>My feeling says:
>
>* ":" on a package should reset a "hold".
>* ":" on a branch should not reset a "hold".
>* This is inconsistent. ;-)
>
>A possible keybinding for "reset" could be ";" (":" without Shift on
>US keyboard layout, not yet used), but then again I think that key
>combo should be even more harder to type than ":" and not be a single
>key strike which can easily be hit unexpectedly.
>
>Looking forward for further comments!

For me, I think that there's no clear way to tell of the boundary in the
relationship between keeps and holds, as you exemplify with the "this is
inconsistent".

On one hand, we (I assume your position) want a way to reset hold and
expect to use "keep" on an individual level, even if curiously in the
documentation only mentions "install" to reset a hold (it does not, just
applies other action, which might have no effect if there is no
candidate version).

(By the way, it is unfortunate for this case that in aptitude in general
there is no "tradition" that e.g. uppercase reverse lowercase actions.
And it is impossible to stablish by now, with 'c' and 'C' for example.
In any case, "shift+=" is "+", so it wouldn't help in this case.)

On the other hand, we don't want "keep-all" (or pressing ":" on trees)
to remove the holds. I also think that this is inconsistent, and I am
not very happy about this solution. I also don't like to much changing
current, long-standing and documented practices, unless there is a very
compelling reason to do so -- you never know when you're breaking
people's usercases; specially if they went to the problem to read the
documentation and so on and are relying on this, and there are no easy
switches to an equivalent solution. We don't know if there are such
usecases, that's one of the problems :-)

But I also think that we could and could do something about this.

- Changing the behaviour of "keep-all" is maybe a bit "risky" but its
effects on holds seem to be largely undesired/unintuitive, and it is
already not documented to remove holds.

In the command line, there is an easy workaround to also reset holds
if one needs that ("unhold ~ahold"), and we can create a command
"unhold-all" if there were many complaints (but I would prefer not to
create even more commands, and esp. document and then translate them
:-P). Also, other actions like install/upgrade would reset the hold,
so people can get out of it easily.

- If it works in this way as well (resetting holds), I would like to
change the behaviour of "keep" to do the same as "keep-all". Both
should be consistent, and "-all" should be just applying "keep" to all
packages, that's all.

- "Cancel pending actions" is not strongly attached to "keep", so since
people are annoyed about the side-effects, we could easily change the
behaviour, command description and the documentation... and hope for
the best.

If there are complaints, we can provide "Cancel pending actions,
including holds", or "Unhold all packages currently on hold".


So far is like Axel's proposal, just using concrete and existing names,
and that maybe we can skip implementing a menu option to unhold-all.

Does everybody agree on these ones so far?


But I am still not happy with the shortcuts in the interactive mode,
because apart from being inconsistent between ":" on individual packages
and subtrees, it is inconsistent with all of the shortcuts that work in
the same way. Except 'F', which I found that it doesn't apply to
subtrees -- it doesn't make sense in this case, unless the subtree is
composed by packages from the same source and with the same version.
(And I don't think that it's as widely used feature as most).

Perhaps ";" or equivalents in the end is the only solution that we have,
but I think that we should avoid to add yet another way to do this and
specially not address the inconsistent behaviour; because people might
continue to complain that "':' does not work in the same way in
subtrees!"; and so instead of solving 1 problem we could create 2
problems.

And also inconsistent is that, if keep doesn't mean "unset hold" in the
command line, ":" or Menu-Keep shouldn't do it in interactive mode. In
which case we would really need a new key to unhold.

Bother :-/

[Osamu Aoki]

Hi,

On Sun, Sep 20, 2015 at 01:56:29AM +0100, Manuel A. Fernandez Montecelo wrote:
> ...

> Note that the help that appears in the bottom of the screen when you
> "hover" over that option in the menu is:
>

> "Cancel all pending installations, removals, holds, and upgrades."

Hmmm... I overlooked this. Very true. (I saw your another post which
details info from the manual.)

> ...

> I do not have a strong preference, and there is some sense in what you
> say, but it seems that this has been done on purpose and by design.
>
> (As a data point, I almost never used this option, BTW).

When I was living under the sid system, aptitude started with mass
package removal when some library dependence of Gnome packages were not
optimal when it is started with "aptitude -u" option" or when you hit
"u" to update the package list. This update action not only downloads
the package list but also update selected packages and suggests package
version updates and removals.

Maybe problem has been tamed by now and you may not be seeing it.

What was needed was a way to get back to the state just after the
package list download but with no auto selected update and removal
choices.

On Fri, Sep 25, 2015 at 08:01:55PM +0100, Manuel A. Fernandez Montecelo wrote:
> 2015-09-20 15:11 Axel Beckert:

> ...

> I found that it is also documented in the manual, and says:

True. It is well documented.

>...

> >>But in the UI, I think that there would be no way to reset the hold
> >>state of all packages on hold, without going one by one and resorting to
> >>the command line.
> >>
> >>So if we simply change the menu option without offering alternatives,
> >>maybe some users which already rely on this functionality are not happy.
> >
> >Yep. I think, we should split it up:
> >
> >keep -- reset all install/purge/delete/reinstall scheduled actions
> >reset -- reset all install/purge/delete/reinstall scheduled action plus hold

I was almost bit lost here until I re-read Manuel's summary of the
manual. My initial reaction was ... My concern was "Action"
-> "Update package list"
-> "something similar to Cancel pending actions"
and get back to keep old "hold" and manually resolve dependency.

But I see this is connected to how "Cancel pending actions" is
implemented.

> ................................. I also don't like to much changing

> current, long-standing and documented practices, unless there is a very
> compelling reason to do so -- you never know when you're breaking
> people's usercases; specially if they went to the problem to read the
> documentation and so on and are relying on this, and there are no easy
> switches to an equivalent solution. We don't know if there are such
> usecases, that's one of the problems :-)

Yes, it is true that it takes a lot of enery of DDs to change any
behavour of popular programs.

> But I also think that we could and could do something about this.
>
> - Changing the behaviour of "keep-all" is maybe a bit "risky" but its
> effects on holds seem to be largely undesired/unintuitive, and it is
> already not documented to remove holds.
>
> In the command line, there is an easy workaround to also reset holds
> if one needs that ("unhold ~ahold"), and we can create a command
> "unhold-all" if there were many complaints (but I would prefer not to
> create even more commands, and esp. document and then translate them
> :-P). Also, other actions like install/upgrade would reset the hold,
> so people can get out of it easily.
>
> - If it works in this way as well (resetting holds), I would like to
> change the behaviour of "keep" to do the same as "keep-all". Both
> should be consistent, and "-all" should be just applying "keep" to all
> packages, that's all.
>
> - "Cancel pending actions" is not strongly attached to "keep", so since
> people are annoyed about the side-effects, we could easily change the
> behaviour, command description and the documentation... and hope for
> the best.

Yes.

> If there are complaints, we can provide "Cancel pending actions,
> including holds", or "Unhold all packages currently on hold".
>
> So far is like Axel's proposal, just using concrete and existing names,
> and that maybe we can skip implementing a menu option to unhold-all.
>
> Does everybody agree on these ones so far?
>
>
> But I am still not happy with the shortcuts in the interactive mode,
> because apart from being inconsistent between ":" on individual packages
> and subtrees, it is inconsistent with all of the shortcuts that work in
> the same way. Except 'F', which I found that it doesn't apply to
> subtrees -- it doesn't make sense in this case, unless the subtree is
> composed by packages from the same source and with the same version.
> (And I don't think that it's as widely used feature as most).
>
> Perhaps ";" or equivalents in the end is the only solution that we have,
> but I think that we should avoid to add yet another way to do this and
> specially not address the inconsistent behaviour; because people might
> continue to complain that "':' does not work in the same way in
> subtrees!"; and so instead of solving 1 problem we could create 2
> problems.

Alex's proposal of having 2 internal commands is good one.

keep -- reset all install/purge/delete/reinstall scheduled actions
reset -- reset all install/purge/delete/reinstall scheduled action plus hold

And let "Cancel pending actions" use the "keep" and update documentation
on it.

As for unhold-all, let's make people use existing UI to do that.

How about on TUI, instead of inconsistent behavior:
* press ":" once on the same thing should not reset a "hold". (keep)
* press ":" twice on the same thing should reset a "hold". (reset)

Shift-: is not ; on German, French, and Japanese keyboard :-) But this
double press approach is common for all.

Osamu

[Manuel A. Fernandez Montecelo]

2015-09-26 3:16 GMT+01:00 Osamu Aoki <os...@debian.org>:
>
> When I was living under the sid system, aptitude started with mass
> package removal when some library dependence of Gnome packages were not
> optimal when it is started with "aptitude -u" option" or when you hit
> "u" to update the package list. This update action not only downloads
> the package list but also update selected packages and suggests package
> version updates and removals.
>
> Maybe problem has been tamed by now and you may not be seeing it.
>
> What was needed was a way to get back to the state just after the
> package list download but with no auto selected update and removal
> choices.

Hmm, it looks like you have/had enabled the option "Automatically
upgrade installed packages". I am not sure if Undo also works in this
case, maybe not.

> Alex's proposal of having 2 internal commands is good one.
> keep -- reset all install/purge/delete/reinstall scheduled actions
> reset -- reset all install/purge/delete/reinstall scheduled action plus hold
>
> And let "Cancel pending actions" use the "keep" and update documentation
> on it.
>
> As for unhold-all, let's make people use existing UI to do that.

This doesn't work well. There are loads of people who are completely
unaware that aptitude has a TUI to begin with, when for me it is
clearly the most strinking feature. And this was not in random
encounters with users, but in the last DebConf, with seasoned Debian
developers very integrated in the community and active for many years.

And in general, keeping functionality and behaviour consistent between
different ways of using aptitude is a continous request, there are
lots of bugs reporting differences and asking to correct them.

So I am not sure how to better address this yet (maybe unhold-all is
not needed, or maybe adding reset is a good idea in general), but
keeping and improving consistency in all ways of using aptitude has to
be a design goal when making changes.

> How about on TUI, instead of inconsistent behavior:
> * press ":" once on the same thing should not reset a "hold". (keep)
> * press ":" twice on the same thing should reset a "hold". (reset)
>
> Shift-: is not ; on German, French, and Japanese keyboard :-) But this
> double press approach is common for all.

To be honest, I think that this proposal would also be confusing for
many people. It is changing the current behaviour that many people
are used to after years of muscle-memory (":" already resets holds as
well, individually and in subtrees, I use it routinely and on
purpose), and people old or new might think that this functionality
suddenly starts to bechave erratically and that is not working
properly.

This could translate to more bug reports, a prospect that terrifies me
in general :-), but specially leaving the situation unresolved and
still adding to the problem.


... So in summary yes, I think that there is a problem in what you
originally described, but so far I am not very happy with the solution
for shortcuts. We will have to think a bit more about it.

[Manuel A. Fernandez Montecelo]

Control: tags -1 - moreinfo + pending


Hi all,

2015-09-25 20:01 To Axel Beckert:

>
>- "Cancel pending actions" is not strongly attached to "keep", so since
> people are annoyed about the side-effects, we could easily change the
> behaviour, command description and the documentation... and hope for
> the best.
>
> If there are complaints, we can provide "Cancel pending actions,
> including holds", or "Unhold all packages currently on hold".

I am going to fix this by making "Cancel pending actions" to reload the
cache, which is roughly equivalent to restart the program without
exiting and starting again (effectively forgetting all what was marked
in this session).

I think that this is more consistent with "Cancel pending actions" as
described by the original report and other users, than the previous
behaviour -- removing all holds and auto-installed flags of all packages
in the system, even if they had not been changed in this session.


Most of the other discussion in the report deals with changing "keep"
and "keep-all" behaviours to adhere to what we want to achieve with this
menu action, so instead, by detaching both, we don't have to consider
how fixing this problem affects other use cases.

Conversely, there are many other open bug reports (how "keep" or other
actions reset "hold" status and "auto" flags) which overlap with the
matters discussed in this report, so I think that it's more appropriate
to consider each use case and fix separately and its effects in turn,
rather than globally.

[Ralf Jung]

Hi,

> I am going to fix this by making "Cancel pending actions" to reload the
> cache, which is roughly equivalent to restart the program without
> exiting and starting again (effectively forgetting all what was marked
> in this session).
>
> I think that this is more consistent with "Cancel pending actions" as
> described by the original report and other users, than the previous
> behaviour -- removing all holds and auto-installed flags of all packages
> in the system, even if they had not been changed in this session.

Does this mean that if there is an action stored in the cache, that
action would not be canceled? I think that would also be confusing. It
happens from time to time that the cache contains operations where I
have absolutely no idea where they come from - I just start aptitude,
and suddenly it wants to (un)install stuff. In that case, I just "Cancel
pending actions" to make sure that nothing actually happens.

Kind regards,
Ralf

[Axel Beckert]

Hi,

Ralf Jung wrote:
> > I am going to fix this by making "Cancel pending actions" to reload the
> > cache, which is roughly equivalent to restart the program without
> > exiting and starting again (effectively forgetting all what was marked
> > in this session).
> >
> > I think that this is more consistent with "Cancel pending actions" as
> > described by the original report and other users, than the previous
> > behaviour -- removing all holds and auto-installed flags of all packages
> > in the system, even if they had not been changed in this session.
>
> Does this mean that if there is an action stored in the cache, that
> action would not be canceled? I think that would also be confusing.

I agree with Ralf here. Cancel pending actions should also cancel all
scheduled actions which have been scheduled in previous aptitude runs,
too.

I'm though not sure if by "cache" you mean apt's cache (which would
include holds, but not aptitude's scheduled actions) or aptitude's
extended states file (which would include both).

In the latter case, please note that such things happen as

1. Start TUI
2. Schedule some actions
3. gg -> Start downloading files -- this saves the extended states
4. q -> Abort download
5. Cancel pending actions

[Manuel A. Fernandez Montecelo]

Hi,

2016-01-22 09:03 Axel Beckert:

>Hi,
>
>Ralf Jung wrote:
>> > I am going to fix this by making "Cancel pending actions" to reload the
>> > cache, which is roughly equivalent to restart the program without
>> > exiting and starting again (effectively forgetting all what was marked
>> > in this session).
>> >
>> > I think that this is more consistent with "Cancel pending actions" as
>> > described by the original report and other users, than the previous
>> > behaviour -- removing all holds and auto-installed flags of all packages
>> > in the system, even if they had not been changed in this session.
>>
>> Does this mean that if there is an action stored in the cache, that
>> action would not be canceled? I think that would also be confusing.
>
>I agree with Ralf here. Cancel pending actions should also cancel all
>scheduled actions which have been scheduled in previous aptitude runs,
>too.

It looks to me that different people have different ideas in mind about
how it should work, incompatible between them:

1) One is to discard pending actions of the current session, considering
actions previously scheduled (and saved) and not as "pending [to
save/confirm]", but as "confirmed that I want to go ahead with
those".

This, intuitively, is what makes more sense to me, that's why I was
going to fix it in this way and I thought that it was
uncontroversial.

There's no current way to achieve this, other than by quitting
without saving the state (Control-C, unadvisable in general) plus
starting again or Undo-ing one by one all previous actions in the
section. I'd maintain that this is a more
useful/requested/commonly-used feature than reverting previously
confirmed and saved states.

2) Another is to reset all packages's states to "keep", removing holds
and sometimes auto flags, which is what it is currently doing.

This was done intentionally in this way --and documented-- because
"hold" (and I guess that "auto installed" as well, but it doesn't
make much sense in this case) was considered a kind of transient flag
that should not be present in a normal state of the system, thus
"hold" was considered to be a "pending action" in the same way as
"upgrade", "install" or "remove".

What people were complaining about in these bug reports (#537735,
#576319; and probably others where people complain about the loss of
Hold or Auto without having founding out the cause) is essentially
that "Cancel pending actions" is removing a property that they don't
consider "pending" or transient, but permanent (auto-installed and
holds).

Even without "Cancel pending options" working in this way, the
actions which haven't taken place, can be easily reverted by applying
"keep" on the group of packages that change (searchable with
"!~akeep", for example, or going to the "preview" screen and undoing
that), and perhaps selectively (not cancel all actions at the same
time, but only a subset).

3) Another, what Ralf and you are requesting, is to cancel not only
actions pending in this session, but previously confirmed by saving
them in previous sessions.

(Actually, it looks to me that Ralf is experiencing some other
problem, because it is not normal that aptitude often wants to change
the current state of the system the first time that he fires aptitude
up -- that's because it detects some conflict or brokenness with the
current state. Ralf doesn't like the current behaviour #2 either).

This is fundamentally unattaintable. Actions are immediately saved
to several places, including apt and dpkg accessible files, so if you
mark a package for deletion and quit aptitude, "dpkg --pending
--remove" will remove it. If apt, dpkg or other tools install other
packages in the meantime, or update the available packages, upon
starting aptitude it will re-read the state of the system and will
update things accordingly, removing/invalidating part of the
previously scheduled actions. So one will be unable to undo some of
the "saved but not performed actions [within aptitude]", because
actions would have been performed outside of aptitude.

Additionally, there are many other details to sort out in that case.
"On hold" would never be able to be considered as a "pending action"
(even if it's always described as an action in the doc), and if a
package previously marked as "install" and one does "keep" it in the
current session, "Cancel pending actions" will not set it as
installable in any case. In short, the only way to implement this is
basically how it already works, #2.

Same as with #2, even without "Cancel pending options" working in
this way it's possible and easy to revert these actions, so I don't
think that losing this way to achieve a purpose is a deal-breaker.


So, for me, #3 is not the way to go, and it's a fundamentally flawed
approach (it will never work as intended, as long as aptitude cooperates
with other tools of the ecosystem and doesn't override their actions).

As Maggie and others would have it, There is No Alternative [1].
There's no way but to continue in the path of the integration with other
tools of the Debian package ecosystem, because some of this was
requested since the early days of aptitude back in 2000
(e.g. integration of Holds with apt and dpkg, and only fixed in the
recent 0.7 series), and because saving this information in places
accesible to apt and dpkg is the only sensible way to do it.

[1] https://en.wikipedia.org/wiki/There_is_no_alternative

#2 is what happens now, which doesn't leave people happy, as we've seen
in these reports (and the complaints that "keep" also reset holds).

If we're to keep something like #3, I'd say that we should rename it to
the current #2 "keep all", probably removing holds and all.

#1 (in the form of "Cancel pending actions" as described in #1, or other
possible names such as "Undo all", or "Reset/restart session") is a
missing feature that I want to implement, and I'd argue that what most
people really think that they will achieve when invoking "Cancel pending
actions".

>I'm though not sure if by "cache" you mean apt's cache (which would
>include holds, but not aptitude's scheduled actions) or aptitude's
>extended states file (which would include both).

I mean the same effect as restarting aptitude -- which includes apt
cache plus aptitude bits of data.

>In the latter case, please note that such things happen as
>
>1. Start TUI
>2. Schedule some actions
>3. gg -> Start downloading files -- this saves the extended states
>4. q -> Abort download
>5. Cancel pending actions

As I explained above, this has never worked properly to restore previous
states, and cannot be made to work to reliably rever all actions taken.

"Cancel pending actions" is just a "keep-all" removing holds, equivalent
to press ":" in Upgradable + Installed + NotInstalled subtrees.

[Ralf Jung]

Hi,

> 3) Another, what Ralf and you are requesting, is to cancel not only
> actions pending in this session, but previously confirmed by saving
> them in previous sessions.
>
> (Actually, it looks to me that Ralf is experiencing some other
> problem, because it is not normal that aptitude often wants to change
> the current state of the system the first time that he fires aptitude
> up -- that's because it detects some conflict or brokenness with the
> current state. Ralf doesn't like the current behaviour #2 either).

Nope, there is nothing broken about the current state of the system when
aptitude comes up with pending actions. I can't reproduce the issue, but
I've seen it happen multiple times that one day, I uninstall something
using "apt remove", and the next day, when I start aptitude, it insists
on installing the package again. Same with me using "apt install", and
then later aptitude wanting to remove it.

> This is fundamentally unattaintable. Actions are immediately saved
> to several places, including apt and dpkg accessible files, so if you
> mark a package for deletion and quit aptitude, "dpkg --pending
> --remove" will remove it. If apt, dpkg or other tools install other
> packages in the meantime, or update the available packages, upon
> starting aptitude it will re-read the state of the system and will
> update things accordingly, removing/invalidating part of the
> previously scheduled actions. So one will be unable to undo some of
> the "saved but not performed actions [within aptitude]", because
> actions would have been performed outside of aptitude.

I'm not sure I follow. The behavior I would like to see is certainly
attainable. It can be obtained, for example, as follows (just as a
sketch, of course, this is not practical):

* Store a list of packages marked as "held"
* Run the current "Cancel pending actions"
* Iterate over the stored list, marking every package on it as "held"
again

This is entirely local to aptitude, I do not understand how this should
interact with other tools any more than "Cancel pending actions" already
does right now.



What I am surprised about is the fact that aptitude treats the "hold"
bit and the "automatically installed" bit so very different. As a user,
for me, they are both persistent meta-data that I locally assign to
packages:

auto-installed = I do not actually want this package itself, please
go ahead and remove if it nobody needs it.
hold = I do not want this package's version to change without manual
intervention.

It took me a long time to realize that aptitude, for some (I guess
historic?) reason, treats "hold" as transient. I do not understand why
this is done - it makes no sense in my mental model, since transiently
(i.e., looking at the effect of a single transaction), "hold" and "keep"
are the same: The transaction *does not* have an effect on this package.

> As Maggie and others would have it, There is No Alternative [1].
> There's no way but to continue in the path of the integration with other
> tools of the Debian package ecosystem, because some of this was
> requested since the early days of aptitude back in 2000
> (e.g. integration of Holds with apt and dpkg, and only fixed in the
> recent 0.7 series), and because saving this information in places
> accesible to apt and dpkg is the only sensible way to do it.

Oh, I'm all in favor of hold being integrated with other tools! If I
mark a package as "held" in aptitude, and even "apt upgrade" does not
touch that package, I am happy. (I didn't know this is supposed to work,
will have a closer look at it.) This is yet another reason, actually,
for "Cancel pending actions" *not* to touch the "hold" bit. Again, I
don't see how that interacts with the proposed behavior for "Cancel
pending actions". After all, the "automatically installed" bit is *also*
synced with other tools, and "Cancel pending actions" does not reset
that bit for all packages. Why is "hold" a problem?

Kind regards,
Ralf

[Manuel A. Fernandez Montecelo]

2016-01-22 15:07 GMT+00:00 Ralf Jung <po...@ralfj.de>:
>
>> This is fundamentally unattaintable. Actions are immediately saved
>> to several places, including apt and dpkg accessible files, so if you
>> mark a package for deletion and quit aptitude, "dpkg --pending
>> --remove" will remove it. If apt, dpkg or other tools install other
>> packages in the meantime, or update the available packages, upon
>> starting aptitude it will re-read the state of the system and will
>> update things accordingly, removing/invalidating part of the
>> previously scheduled actions. So one will be unable to undo some of
>> the "saved but not performed actions [within aptitude]", because
>> actions would have been performed outside of aptitude.
>
> I'm not sure I follow. The behavior I would like to see is certainly
> attainable. It can be obtained, for example, as follows (just as a
> sketch, of course, this is not practical):
>
> * Store a list of packages marked as "held"
> * Run the current "Cancel pending actions"
> * Iterate over the stored list, marking every package on it as "held"
> again
>
> This is entirely local to aptitude, I do not understand how this should
> interact with other tools any more than "Cancel pending actions" already
> does right now.

tl;dr: No, it cannot work properly and interact well with the rest of
the tools without saving the state to places common to other tools at
the time of quitting, not only "local to aptitude".


If one marks a package in aptitude as "held", it has to save it
somewhere (currently to dpkg's database of "hold" packages) so that
dselect or apt or other tools respecting those don't attempt to
install new versions. This is saved at the same time when one quits
aptitude, because people expect that marking as Hold and
Auto-installed take effect once one quits aptitude or saves the state
in other ways (e.g. after confirming "preview" and before starting
other actions -- removals, or downloads+installations). I don't know
if all tools respect that yet in all cases, but we've done our bit so
far. After that point, one cannot "cancel that pending action" --
saving the state makes the action of "set on-hold" as permanent,
having being taken.

Same happens with auto-installed flag, only that this has been going
on since forever (or at least about a decade), not a recent thing like
the holds communicated back to dpkg only in the 0.7 series.

Similar problems *happened* (past, not present) with aptitude not
communicating the status of other actions. E.g., marking a package to
upgrade in aptitude but not finishing the upgrade and quitting,
removing the package with apt, then firing up aptitude would mark the
package as to be installed. Many reports about similar sync problems
as well, only addressed in the last few versions.

People expect that all package-management tools in the system
cooperate and don't trip each other. If aptitude does not save it to
the "common areas" or not at the time of saving the state, people will
start to complain again (as it happened in the past) that actions
selected in aptitude are not respected by other tools, and the other
way around.


That's why the concept of "Cancel pending actions" including scheduled
actions in previous aptitude sessions, doesn't make much sense to me.
The rug can be pulled from below the feet of aptitude by other tools
messing with the system at any time in between invocations, and some
of what aptitude traditionally considered actions (e.g. holds) cannot
be undone. That's why I said that it's not possible to have good
cooperation with other tools while being able to cancel pending
actions from previous sessions. And that's why I think that "Cancel
pending actions" only make sense if considering the unsaved state
(i.e., making the previous decisions in this session, *before saving
the state*, be forgotten).

> What I am surprised about is the fact that aptitude treats the "hold"
> bit and the "automatically installed" bit so very different. As a user,
> for me, they are both persistent meta-data that I locally assign to
> packages:
>
> auto-installed = I do not actually want this package itself, please
> go ahead and remove if it nobody needs it.
> hold = I do not want this package's version to change without manual
> intervention.
>
> It took me a long time to realize that aptitude, for some (I guess
> historic?) reason, treats "hold" as transient. I do not understand why
> this is done - it makes no sense in my mental model, since transiently
> (i.e., looking at the effect of a single transaction), "hold" and "keep"
> are the same: The transaction *does not* have an effect on this package.

I can only guess that, given the state of the Debian world and the
packaging tools at the time --and probably aptitude was the tool which
introduced the concepts of "hold"--, "hold" was seen as a exceptional
measure to temporarily address problems with packages entering
unstable, and that the natural state of any package is to not be on
hold -- that's why "keep" et. all reset the "hold" state.

I think that this still applies nowadays, hold should be done very
rarely, not for many packages and not for a long time, otherwise one
can miss crucial security upgrades or similar.

>> As Maggie and others would have it, There is No Alternative [1].
>> There's no way but to continue in the path of the integration with other
>> tools of the Debian package ecosystem, because some of this was
>> requested since the early days of aptitude back in 2000
>> (e.g. integration of Holds with apt and dpkg, and only fixed in the
>> recent 0.7 series), and because saving this information in places
>> accesible to apt and dpkg is the only sensible way to do it.
>
> Oh, I'm all in favor of hold being integrated with other tools! If I
> mark a package as "held" in aptitude, and even "apt upgrade" does not
> touch that package, I am happy. (I didn't know this is supposed to work,
> will have a closer look at it.)

It should work since a few versions ago.

> This is yet another reason, actually,
> for "Cancel pending actions" *not* to touch the "hold" bit. Again, I
> don't see how that interacts with the proposed behavior for "Cancel
> pending actions". After all, the "automatically installed" bit is *also*
> synced with other tools, and "Cancel pending actions" does not reset
> that bit for all packages. Why is "hold" a problem?

I think that you misunderstood my message.

The main complaint of this report was that "Cancel pending actions"
unholds packages, and I was proposing to solve it by "Cancel pending
actions" only ignoring the actions taken in the current aptitude
session (this includes ignoring "holds" set so far in the current
session, but not in previous sessions). That was my example #1 in the
previous message, and I don't want "Cancel pending actions" to
continue to unhold all packages, which is what currently happens
(example #2).

Setting packages on "hold", or marking them as to be "purged" etc.,
has to be saved and communicated to other tools when aptitude quits,
at which point cancelling those previously scheduled actions (my
example #3) is not [always] possible, which was Axel point based on
your use-case/reply to my message. And in particular, "holds" are not
a scheduled action like others -- once saved, one doesn't know if it
comes from the last session or from very long ago or from other tools.