XPost: linux.debian.policy

On Mon, 11 Sep 2023 21:27:09 -0700 Russ Allbery <rra@debian.org> wrote:

Control: retitle -1 Document the Protected field

Adam Borowski <kilobyte@angband.pl> writes:

On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote:

Do you have any idea how long we can expect to wait until dpkg supports
the field? I would suggest that we wait until dpkg has defined
behaviour for the field, as it will make documenting it much easier.
It will also allow us to be more confident that there is no serious
disagreement about the purpose of the field.

Right, let's have dpkg maintainers tell us what they think.

I couldn't find a bug against dpkg, but if there is one, it should
probably be set to block this bug.

872587 < 872589, I filed the Policy one first. Block added.

Per the resolution of #872589, this was implemented as the Protected field instead. Retitling the bug accordingly.

The documentation from deb-control(5) is:

Protected: yes|no
This field is usually only needed when the answer is yes. It denotes
a package that is required mostly for proper booting of the system or
used for custom system-local meta-packages. dpkg(1) or any other
installation tool will not allow a Protected package to be removed (at
least not without using one of the force options).

It's probably also worth noting the parenthetical comment in the documentation of Essential:

Essential: yes|no
This field is usually only needed when the answer is yes. 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 Protected field instead). dpkg(1) or any other
installation tool will not allow an Essential package to be removed
(at least not without using one of the force options).

I'm still not sure that I inderstand the difference between those two.
They seem to accomplish the same thing. Did I miss something?

It should also be noted that, as of version 2.117.0, Lintian still
gives a warning whenever a binary target has the Protected field set.

Martin-Éric

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.policy

On Wed, Mar 27, 2024 at 01:29:50PM +0200, Martin-Éric Racine wrote:

The documentation from deb-control(5) is:

Protected: yes|no
This field is usually only needed when the answer is yes. It denotes
a package that is required mostly for proper booting of the system or
used for custom system-local meta-packages. dpkg(1) or any other
installation tool will not allow a Protected package to be removed (at
least not without using one of the force options).

It's probably also worth noting the parenthetical comment in the documentation of Essential:

Essential: yes|no
This field is usually only needed when the answer is yes. 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 Protected field instead). dpkg(1) or any other
installation tool will not allow an Essential package to be removed
(at least not without using one of the force options).

I'm still not sure that I inderstand the difference between those two.
They seem to accomplish the same thing. Did I miss something?

Per my understanding which may be flawed:

"Essential: yes" are always installed. Tools and dependencies assume they
are installed. Bootstrapping tools install them implicitly. Package
management tools refuse to remove them.

"Protected: yes" are nothing like that. Package management tools refuse to remove them and that's all.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmYECVUtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh cO0P/AsUEgObdrIce8w+77bihDt4+tNx3Mq6nb+Uim3zdeYuTkjR+GvUkw53vmFJ vNlbxhSCzbHFb02ex/wW9Nux6YskhiuKN/MAQQxOIInQvdCTPL3hkftv8Qn0AGqR LTqncIW3OLOWosUC2rmvlXiAX2Gx1FGoCcJeIy4P4YFujL0wuGhtl19ZTkVjWp2b FGHeDmPnZ7BJcQ+wuR3T2BPRmgPjQnqa1SzPHmGlUY23LbPRq7L5qhT8Y1vULULC wkQ3BtNeFBZORuBA5thZRirrHp8SW80HiqaKo20wPeaHCWrp7ZkuHtNLhCf6iPsQ MaEcgnu7RNg8MdnAaed+5ZgkE2/jyS4i64c2GQqocN59kR5IAC4mvQvmMO2bYtbE cQfkXmTWflPTYzGbR57cgcbjJsiSAyoJobD5kOAeXmxYNbcv641V24WUyQNo/2XX z47cXSBaZBEAG69QoCfunpdKfZ13qG/ytKKV9xBAXMvkisyYdX9+p/n7ISqGgnzm etaK5vQhHYlgGxto2gR/18GhAfb4n4/+hsZWYHo7jRlxlXODLuzeS16FL+JQDfxR 5CoAnAkN8sknP+plZ9wmN3T6Jdz1eXV+45EvITiaiNtRsNE95O1XA5qYHma8kH0P hqdBWyQkEIYc0cqjIL6VQYwUELohO6Pg25pp5W+sCyk8hdE8
=i4Vw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.policy

On Wed, 27 Mar 2024 at 14:43:40 +0200, Martin-Éric Racine wrote:

ke 27. maalisk. 2024 klo 14.00 Andrey Rakhmatullin (wrar@debian.org) kirjoitti:

"Essential: yes" are always installed. Tools and dependencies assume they are installed. Bootstrapping tools install them implicitly. Package management tools refuse to remove them.

"Protected: yes" are nothing like that. Package management tools refuse to remove them and that's all.

Another way to look at this is that if a Protected package is already installed, then package management behaves as though it's Essential,
but if a Protected package is merely available from a configured apt
source, then nothing special happens.

Protected: yes|no
This field prevents a package from getting auto-removed by dpkg
without using one of the force options.

True so far...

It is intended for custom
local packages not meant for upload to the Debian repository.

... but this isn't the whole story. Protected: yes is also appropriate
for non-local packages that are required for system boot, or for package management. The design principle is that if it would be hard to recover
from removing a package once it has been installed, then it's Protected.

An example of Protected: yes on boot packages is that the init metapackage
is Protected: yes, to make sure you don't accidentally remove the init
system and make the system unbootable (which is hard to recover from
because before you can install a new init system, you need to be able to
boot). It might also make sense for bootloaders like grub to be Protected:
yes, although currently they are not.

An example of Protected: yes on package management packages is that it
would be appropriate to put Protected: yes on apt (although in fact apt
is hard-coded to behave that way even without Protected: yes), to avoid accidentally getting into a situation where you have removed apt
(which is hard to recover from because now there's no package manager,
and no easy-to-validate trust chain to check that a manually-downloaded apt_*.deb is authentic).

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)