Hi! On Fri, 2022-04-01 at 14:41:51 +0200, Stephen Kitt wrote: > Package: dpkg > Version: 1.20.9 > Severity: normal
> Protection is applied to foreign-arch packages (e.g. libgcc-s1:i386 on > amd64) even though they aren't relevant to the scenarios that > protection is designed to prevent (as I understand it): Right, AFAIR this was a workaround used to try to help apt with an upgrade scenario where otherwise it was unable to cope well with the libgcc1 to libgcc-s1 transition. > > Protected packages contain mostly important system boot > > infrastructure. Removing them might cause the whole system to be > > unable to boot, so use with caution. > > Would it be possible for removal of such packages not to require > --force-remove-protected, at least if the corresponding native arch > package is installed? The latter check isn't useful with libraries > (where, if nothing depends on them, we can be certain that they are > not needed for the system to boot), but would catch situations where > e.g. the system's init is not the native package. (I imagine there's a > better approach to this.) In principle shared libraries should never be marked Essential:yes nor Protected:yes, I think this was a special case, that will go away once the shared library gets the Protected filed dropped after the transition is over. I think at least the description for the field in dpkg(1), deb-control(5) and probably «/usr/share/doc/dpkg/protected-field.txt» should be made more clear. I'll try to prepare a patch for this today. And while I think in this specific case that you mention, the heuristic that you propose might make sense. I'm not sure that is generalizable or can be encoded in a neutral way in dpkg itself. As I don't think it would be appropriate for dpkg to assume that all Mulit-Arch:same packages are going to be shared libraries, or say encode specific package name patterns or even assumed semantics out of section names. Thanks, Guillem
