RFC: Standardizing a new Protected field

[Guillem Jover <guillem@debian.org>]

Hi!

Summary
-------

The goal of the following proposal is to standardize a field to split
part of the Essential packages, and add support for it in the package
management stack. There is currently an Important field, that has the
correct semantics but has a very confusing name and is only supported
by apt anyway, so this new field would phase out that one.


Background
----------

Our current use of Essential:yes is confused, and it includes several
conflated things, some of which would be worth splitting up.

We use Essential to:

  - denote that a package must be always installed and cannot be
    removed (easily), because it's essential to the system in some way.
  - denote that a package must be functional even when just unpacked
    (after having been configured once / fully bootstrapped).
  - mark auto-vivification, by making frontends either complain very
    loudly or reinstalling these packages when missing.
  - minimize dependency loops, by making these dependencies implicit.

One problem is that the first point above includes being essential for
the packaging system during upgrades/installation, for the operation
of the system in general, and for the operation of the system during
boot.

The latter is not always necessary though, for example within a chroot,
or some types of containers. There's been work on trying to trim down
the pseudo-essential set as can be seen from:

  <https://wiki.debian.org/Proposals/EssentialOnDiet>
  <https://wiki.debian.org/BusterPriorityRequalification>

And several of these switches made use of a pre-existing field called
Important, defined and currently only supported by apt, which had the
following properties:

  - these packages are not required to be installed.
  - they do not have to be usable while unconfigured.
  - dependencies need to be spelled out.

Proposal
--------

Julian Andres Klode and I have been discussing this from time to time,
and collected some of our thoughts in:

  <https://wiki.debian.org/Teams/Dpkg/Spec/ProtectedField>

The proposal would be to add support for a new Protected field, with the
following properties:

  - Protected packages should not be trivial to remove (require a force
    option for example, like Essential).
  - Protected packages should not be required to be installed (i.e. once
    removed they should not be automatically brought back by a frontend,
    unlike Essential).
  - Protected packages must be depended on explicitly (unlike Essential).
  - Protected packages must be functional even when unpacked (think of
    a boot loader or an init system; like Essential). [XXX: This one is
    not entirely clear and might not match reality anyway, e.g. kernels,
    which might require building an initramfs, etc.]

This would make it possible to phase out the current Important field
usage (because it has a too confusing name relative to the Priority
value; and has small tooling coverage) and the usage of Essential for
at least packages involved in the boot process, and perhaps also for
packages essential for operation of the system in general (in contrast
to packages required for the packaging system).

This would require minor changes in apt, and there's already a branch for
dpkg at:

  <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/protected-field>

Thanks,
Guillem