Hi Guillem, On Sat, 2 Apr 2022 15:09:26 +0200, Guillem Jover <guil...@debian.org> wrote: > 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.
Ah right, that’s good to know, thanks! It seems libcrypt1 is protected for upgrade reasons too. > > > 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. Excellent! > 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. Right, I didn’t have the latter in mind; I was hoping that a heuristic like “when removing foo:foreign, if foo:native is installed then ignore the protected field” would work, without considering foo’s section etc. Regards, Stephen
pgpzHvdBS6BR5.pgp
Description: OpenPGP digital signature
