Bug#1008780: dpkg: protection shouldn't apply to foreign-arch packages
Hi! On Sun, 2022-04-03 at 19:00:33 +0200, Stephen Kitt wrote: > On Sat, 2 Apr 2022 15:09:26 +0200, Guillem Jover wrote: > > 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! I've got the attached, although it would probably not have been enough. But I'm a bit hesitant to mention the workaround case, as don't feel it's supposed to be used that way, and it looks more like an exception than something proper. But then, if people find these cases, then not mentioning it might be more confusing, so hmmm. If I had to mention that I'd perhaps add something like these lines: other uses ", and in some very special circumstances it might be used as a workaround to help with upgrade scenarios that front-ends might not be able to resolve in some other more proper way" but, not sure. Thanks, Guillem diff --git i/man/deb-control.pod w/man/deb-control.pod index 9f1de6a21..e5ec89abd 100644 --- i/man/deb-control.pod +++ w/man/deb-control.pod @@ -121,7 +121,8 @@ The algorithm to compute the size is described in L. =item B B|B This field is usually only needed when the answer is B. -It denotes a package that is required for proper booting of the system. +It denotes a package that is required mostly for proper booting of the system +or used for custom system-local meta-packages. L or any other installation tool will not allow a B package to be removed (at least not without using one of the force options). @@ -130,7 +131,9 @@ Supported since dpkg 1.20.1. =item B B|B This field is usually only needed when the answer is B. -It denotes a package that is required for proper operation of the system. +It denotes a package that is required for the packaging system, for +proper operation of the system in general or during boot (although the latter +should be converted to B field instead). L or any other installation tool will not allow an B package to be removed (at least not without using one of the force options). diff --git i/man/dpkg.pod w/man/dpkg.pod index e6abd3d3f..f09b7c0d1 100644 --- i/man/dpkg.pod +++ w/man/dpkg.pod @@ -700,14 +700,18 @@ remain on the system, which will then be forgotten by B. B: Remove, even if the package is considered protected (since dpkg 1.20.1). -Protected packages contain mostly important system boot infrastructure. -Removing them might cause the whole system to be unable to boot, so use -with caution. +Protected packages contain mostly important system boot infrastructure or +are used for custom system-local meta-packages. +Removing them might cause the whole system to be unable to boot or lose +required functionality to operate, so use with caution. B: -Remove, even if the package is considered essential. Essential -packages contain mostly very basic Unix commands. Removing them might -cause the whole system to stop working, so use with caution. +Remove, even if the package is considered essential. +Essential packages contain mostly very basic Unix commands, required for +the packaging system, for the operation of the system in general or during +boot (although the latter should be converted to protected packages instead). +Removing them might cause the whole system to stop working, +so use with caution. B: Turn all dependency problems into warnings.
Bug#1008780: dpkg: protection shouldn't apply to foreign-arch packages
Hi Guillem, On Sat, 2 Apr 2022 15:09:26 +0200, Guillem Jover 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 pgpiVXL4Q496Q.pgp Description: OpenPGP digital signature
Bug#1008780: dpkg: protection shouldn't apply to foreign-arch packages
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
Bug#1008780: dpkg: protection shouldn't apply to foreign-arch packages
Package: dpkg Version: 1.20.9 Severity: normal Dear Maintainer, 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): > 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.) Regards, Stephen -- Package-specific info: -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.10.0-12-amd64 (SMP w/8 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.31-13+deb11u3 ii liblzma5 5.2.5-2 ii libselinux1 3.1-3 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.2.4 ii debsig-verify 0.23+b2 -- no debconf information
