[Aptitude-devel] Bug#1082745: Bug#1082745: aptitude: information mismatch for package removal
Axel Beckert
abe at debian.org
Thu Nov 7 23:50:14 GMT 2024
Control: clone -1 -2
Control: retitle -1 aptitude: Marks some autoinstalled dependencies not immediately for removal if last reverse dependency is removed (but switching rev-dep from removal to purging helps)
Control: severity -1 important
Control: tag -1 + help
Control: retitle -2 aptitude: TUI does not show all package action changes if package actions are changed while already in preview
Control: severity -2 wishlist
Hi Vincent,
> This issue occurred again for the new Linux kernel upgrade.
> Here's additional information.
Thanks, that helps a bit.
> The reformatted diff on the /var/lib/aptitude/pkgstates file
> just after the upgrade:
[…]
> Package: linux-image-6.10.12-amd64
> Architecture: amd64
> Unseen: yes
> State: 1
> -Dselect-State: 0
> +Dselect-State: 1
> Remove-Reason: 0
> -Auto-New-Install: yes
For me this looks as if linux-image-6.10.12-amd64 is marked as to
be installed automatically via dependency.
> and "apt install -f -s" outputs
>
> The following packages were automatically installed and are no longer required:
> linux-headers-6.10.9-amd64 linux-headers-6.10.9-common linux-image-6.10.9-amd64 linux-kbuild-6.10.9
Yes, this tells us that linux-image-6.10.9-amd64 was marked as
automatically installed, too.
> but note that aptitude does not say anything about the old kernel
> image linux-image-6.10.9-amd64 in the /var/lib/aptitude/pkgstates
> diff above. It still has:
>
> Package: linux-image-6.10.9-amd64
> Architecture: amd64
> Unseen: yes
> State: 1
> Dselect-State: 1
> Remove-Reason: 0
Correct. It wasn't to be uninstalled at point, too, as you wrote:
Vincent Lefevre wrote:
> In its TUI, aptitude initially says, just after the upgrade:
>
> Packages Preview
> aptitude 0.8.13 @ cventin Disk: -67.6 MB
> --\ Packages being removed because they are no longer used (3)
> idA linux-headers-6. -4012 kB 6.10.9-1 6.10.9-1
> idA linux-headers-6. -61.4 MB 6.10.9-1 6.10.9-1
> idA linux-kbuild-6.1 -2271 kB 6.10.9-1 6.10.9-1
>
> and no other packages are marked as to be removed (not even
> linux-image-6.10.9-amd64).
>
> Just after hitting '_' over "Packages being removed because they
> are no longer used", I get
I think here's the main issue(s):
Any interactive package action change makes aptitude reevaluating the
state of all related packages, especially in the case of removal or
purging all dependencies marked as "automatically installed" to see if
they need to be removed, too.
In general this reevaluation is needed for the options
* "Automatically resolve dependencies of a package when it is
selected",
* "Automatically fix broken packages before installing or removing",
and
* Remove unused packages automatically.
I suspect the latter setting is involved here.
I wonder though, why does aptitude reevaluate these states if a
package changes from removal to purging as this only changes if the
configs are removed, too, or not. The package will be removed in both
cases. Might be something which just hadn't been optimised out.
There are known cases where aptitude removes unneeded packages only
upon a second evaluation (usually after update/install/remove run)
that a package can be removed. (My suspicion here is aptitude's
resolver being not perfect around Provides.) But I think that one's
not involved here as there seem no Provides involved.
What is likely involved here is https://bugs.debian.org/902652 which
refers to
src/generic/apt/aptcache.cc:2664: std::string matchterm = aptcfg->Find(PACKAGE "::Keep-Unused-Pattern", "~nlinux-image-.*");
i.e. that aptitude has still something like "never autoremove packages
starting with 'linux-image-'" hardcoded. But this issue as well as the
fact that enough older kernels (but IIRC never the currently running
one) have been proposed for automatical removal in aptitude to me,
shows that it is only conditionally applied.
So there's definitely a bug in here that triggers the removal of
additional packages if a package, which is already marked for removal,
is later also marked for purging despite it previously didn't consider
that additional package.
I though don't think that's a grave bug. From my experience it's an
annoying but seldom happening one. And it's IMHO the bug which needs
to fixed here.
What happened in your is that it appeared together with something
which is as far as I can see not a bug but a design decision:
> Packages Preview
> aptitude 0.8.13 @ cventin Disk: -172 MB
> --\ Packages being removed because they are no longer used (3)
> ipA linux-headers-6. -4012 kB 6.10.9-1 6.10.9-1
> ipA linux-headers-6. -61.4 MB 6.10.9-1 6.10.9-1
> ipA linux-kbuild-6.1 -2271 kB 6.10.9-1 6.10.9-1
>
> In particular, the "Disk:" value has changed. And still no other
> packages are marked as to be removed, which is contradictory
> with the change of the "Disk:" value.
Please note: The grouping and limiting of a view in aptitude is never
automatically updated, as this would cost a lot of time after every
package action change. You might have noticed how much time building a
view can take if a system is under load or quite some sources are
listed in /etc/apt/sources.list*.
Package action changes only update the status line on top and the
color and first column of the packages whose action changed (either by
explicitly selecting an action or by dependency resolution).
It does not add packages to a view which is limited to a specific set
of packages nor does it update their grouping. (Changing the latter
would also make the UI unusuable.)
> After hitting 'qg', I get:
That's one way to update the limiting and grouping. Another one is to
press "l<Enter>" which would set a new limited view, but you just keep
applying the same limit (which is actually not limit implicitly used
in the preview, but is actually applied on top of it, but it triggers
a rerendering of the current view.)
> Packages Preview
> aptitude 0.8.13 @ cventin Disk: -172 MB
> --\ Packages being removed because they are no longer used (4)
> ipA linux-headers-6. -4012 kB 6.10.9-1 6.10.9-1
> ipA linux-headers-6. -61.4 MB 6.10.9-1 6.10.9-1
> idA linux-image-6.10 -104 MB 6.10.9-1 6.10.9-1
> ipA linux-kbuild-6.1 -2271 kB 6.10.9-1 6.10.9-1
>
> Now linux-image-6.10.9-amd64 is marked as to be removed
> (and has 'd' instead of 'p').
All correct and as expected after pressing "qg" (or "l<Enter>").
> It seems that contrary to apt, aptitude detects too late that
> linux-image-6.10.9-amd64 should be removed,
Yes.
> with 2 consequences
> when hitting '_' to purge instead of just remove:
> * aptitude adds linux-image-6.10.9-amd64 to the package to be
> removed,
Yes.
> but the user is not notified,
More or less yes as the view doesn't already show that package that
suddenly is involved due to user interaction in the preview.
> so this is big surprise if the user does not do 'qg' first, and
> possibly incorrect and too late if the user does not want to
> remove this kernel image (e.g. because the newer images are
> broken).
If you change package actions as late as in the preview of what would
be done, you should always regenerated that view to see the complete
impact, yes. As mentioned, dynamically adding (or removing) packages
from a view requires rebuilding that view, which takes quite a time.
And it also removes the focus on which package was interactively
selected and closes all opened subtrees. That's nothing you want in a
UI if you just mark a package for removal or installation.
The same counts e.g. if you skim through the recommended and suggested
packages and mark one of the as to be installed: It's additional
dependencies aren't added to the current preview either.
So while there are clearly unlucky implications, the view generation
would need to be rewritten and the view concept redesigned to change
that behaviour. That IMHO would be a feature request which comes close
to a rewrite of the TUI of aptitude.
> * linux-image-6.10.9-amd64 will just be removed, but not purged.
Which is btw. totally correct as you didn't press _ on it. (Unless you
have APT::Get::Purge set to true value. If the later was the case,
that might be a separate, minor bug in aptitude.)
Regards, Axel
--
,''`. | Axel Beckert <abe at debian.org>, https://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
More information about the Aptitude-devel
mailing list