Hi! On Wed, 2024-07-17 at 15:24:36 +0100, Simon McVittie wrote: > Package: dpkg > Version: 1.21.22 > Severity: wishlist
> Before Debian trixie, login was Essential; now it's merely Protected > (included in normal installations, but removable). > > In minimal container environments where logins and package management > are not required functionality, it can be useful to remove Essential and > Protected packages. For example, https://salsa.debian.org/smcv/flatdeb > (used in Valve's Steam Runtime) is intended for single-user, Flatpak-like > app containers with an immutable /usr, so it removes login, passwd > and eventually dpkg to save some space in the container, using dpkg > --force-remove-essential to make that happen. (Obviously this breaks some > normal things in that container, but that's OK for my particular use-case.) > When login became non-Essential, this regressed: now that login is > Protected, `dpkg --force-remove-essential --purge login` refuses to > remove it, even though being Protected is "weaker" than being Essential: I don't think protected can be considered weaker in absolute terms, I think this depends on the context. For the packaging system, Essential is indeed the stronger field, so in a normal chroot scenario that will also be stronger than Protected. For the host system Protected is going to be used among other things to preserve bootability, which I'd say makes it the stronger field, as for a user, being unable to boot is going to be worse than being able to use dpkg, and once booted the packaging system can be more easily recovered (probably). > 2024/07/15 04:30:34 platformize | dpkg: error processing package login > (--purge): > 2024/07/15 04:30:34 platformize | this is a protected package; it should not > be removed > > and even though it does allow Essential packages to be removed: > > 2024/07/15 04:30:34 platformize | dpkg: warning: overriding problem because > --force enabled: > 2024/07/15 04:30:34 platformize | dpkg: warning: this is an essential > package; it should not be removed > > I think it might make sense for --force-remove-essential to automatically > enable the "weaker" option --force-remove-protected - if we're in a > scenario where removing Essential packages is OK, then it's certainly OK > to remove packages like login that are only Protected. See above. > A workaround is to detect the dpkg version in use, and if it's >= 1.20.1, > add --force-remove-protected to the dpkg command-line. The expected way to detect whether you might need to pass that option is to use «dpkg --assert-protected-field» and checking the exit code, which is the way apt is doing that too. I assume part of the rationale for filing this report might have been so that the logic in the caller can be simplified, by making it not care about the support in dpkg *and* the state of packages that change over releases. But the semantics of the requested change does not seem ideal, and a tool that explicitly removes a list of packages is going to be somewhat distro/release specific anyway. So I'm inclined to close this report. Thanks, Guillem
