[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#872587: Document the Protected field



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


Reply to: