Add options to purge packages removed during upgrade

[RomanValov]

The u-u script works great making upgrade delivery non a head ache. However due to frequent upgrades my machines keep lots of kernel packages in a deinstall state. I believe remove is used over purge to avoid removal of custom crafted configuration files. But I assume it's rarely a case for kernel upgrades.

Anyway the proposal is add per-category option to use purge over remove, i.e.:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Purge-Unused-Kernel-Packages "false";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::Purge-New-Unused-Dependencies "false";
Unattended-Upgrade::Remove-Unused-Dependencies "false";
Unattended-Upgrade::Purge-Unused-Dependencies "false";

or introduce third-state for option string value:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "purge";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::Remove-Unused-Dependencies "false";

[paddy-hack]

I ran into something similar. I have

APT::Get::Purge "true";

in my APT configuration and had expected unattended-upgrades to honour that.

Yet, I saw

$ dpkg --get-selections | grep deinstall
linux-image-5.19.0-1025-aws         deinstall
linux-modules-5.19.0-1025-aws           deinstall
$ apt list '~c'
Listing... Done
linux-image-5.19.0-1025-aws/jammy-security,jammy-updates,now 5.19.0-1025.26~22.04.1 amd64 [residual-config]
linux-modules-5.19.0-1025-aws/jammy-security,jammy-updates,now 5.19.0-1025.26~22.04.1 amd64 [residual-config]

I took a peek at the code and noticed that the purge argument is not used in the mark_delete() calls. Passing the configured value should fix this.

Of course, it will not purge configuration files for already removed packages but only for packages removed after the fix. BTW, this issue is not specific to kernel packages.

I could prepare a PR if interested.

[paddy-hack]

Purging configuration files for already removed packages can be achieved with one of

sudo apt purge $(dpkg --get-selections | grep deinstall | cut -f1)
sudo apt purge '~c'

[paddy-hack]

I've been using the changes from the PR and am seeing

Purging configuration files for $package ($version) ...

messages in the /var/log/unattended-upgrades/unattended-upgrades-dpkg.log.

So far so good, but I still end up with packages with what apt calls "residual config". Most prominent of these are the linux-image-$version-aws packages in my Ubuntu Jammy AMI. My attention was caught by

Purging configuration files for linux-modules-6.2.0-1010-aws (6.2.0-1010.10~22.04.1) ...
dpkg: warning: while removing linux-modules-6.2.0-1010-aws, directory '/lib/modules/6.2.0-1010-aws' not empty so not removed

Checking that directory there were indeed files left. Checking /var/lib/dpkg/info/linux-*-6.2.0-1010-aws.*, there was an empty *.list file as well as a *.postrm for the corresponding linux-image package. Its *.postrm contained code that would have removed all the files still lingering in that directory.

Purging the corresponding linux-image package manually removes the directory. I suspected an ordering issue, due to Unattended-Upgrade::MinimalSteps "true";, but the linux-image-* and linux-modules-* appear to always get removed together. Wondering if this is a linux-* package specific issue.

However, I have also seen this happen with other packages not in any way Linux kernel related. Recent examples include landscape-common, ntfs-3g, python-twisted, tcl8.6 and usb-modeswitch. I marked these automatically installed, making them candidates for auto-removal, and unattended-upgrades obligingly removed them. However, "residual config" was left behind for some reason.

Checking the .postrm files, what was left were not configuration files but bits and pieces that the postrm still had to handle. These scripts exit at the first failed command, courtesy of set -e, but I couldn't find any reason they would exit prematurely.

Running apt purge manually succeeds without issue, gets rid of the "residual config" and appears to have executed the postrm scripts fine.