Comment 5 for bug 1969353

I looked into the details, and my conclusions are that the grub-customizer package has a completely broken removal/upgrade story.

The package only installs some binaries, without any custom maintainer scripts or fancy things. Once you run the main program, it goes and modifies the /etc/grub.d scripts automatically for you to customize them as specified. That part already feels weird to me, but wouldn't necessarily cause problems.

However, there are some customizations that are apparently not doable by simply editing the existing configuration scripts. For those, the program moves all existing conf scripts out of the way, and instead installs "proxy scripts" written in a custom language that basically filter the output of the original scripts. The language interpreter is a standard ELF binary with standard dynamic linking, which seems to need the whole Qt stack for some reason. Said interpreter is copied to /etc/grub.d/bin/grubcfg_proxy, presumably so that the system keeps working even if the user uninstalls grub-customizer.

That logic is actually broken, since removing the grub-customizer package might lead to the removal of its dependencies, e.g. the Qt stack, leading to a broken binary.

My suggestion for the path forward would be to patch the application to have /etc/grub.d/bin/grubcfg_proxy be a shell script that invokes the dpkg-managed proxy if it's available, else prints out a warning and executes the original script. We couple that with a post-rm maintainer script that ensures that the /etc-installed script is the one from the current version of the package. We'd need to SRU this to Impish, Focal, and Jammy.

That wouldn't fix every issue with the package, notably leaving the purge situation still broken, but at least that'd fix the problem at hand.

Thoughts?