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 <a...@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
