Differences between revisions 15 and 16
Revision 15 as of 2021-02-22 15:34:27
Size: 4538
Editor: GuillemJover
Comment: Update status
Revision 16 as of 2021-02-23 02:44:51
Size: 4504
Editor: PaulWise
Comment: use mid macros for the mail link
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * '''RFC Thread:''' https://lists.debian.org/msgid-search/?m=20200309092336.GA15210%40gaara.hadrons.org  * '''RFC Thread:''' <<mid(20200309092336.GA15210@gaara.hadrons.org)>>

This draft is out-of-sync with the RFC thread proposal and /usr/share/doc/dpkg/protected-field.txt, requires a resync.

Introduction

APT supports an Important field, similar to Essential, with the following differences:

  • Important packages are not required to be installed.
  • They do not have to be usable while unconfigured.

Background

The name Important is an historic artifact. APT always understood Important as a synonym to Essential, but the meaning was relaxed a few years ago when the field was repurposed for system-configuration meta packages.

Julian Andres Klode proposed afterwards (on the #debian-dpkg IRC channel) naming this field instead Protected which might be less confusing than Important as that's already a Priority value. The name might still not be optimal, because Protected is a tad generic, which can always be solved with documentation, but if better names can be found we are interested!

We'd like to push the support for this concept downwards in the packaging stack.

Definition: Protected packages

Protected defines packages that must not be easily removed from the system once installed. For example, an init system might be marked Protected to not be removed easily from non-container systems.

They should supply their core functionality while unconfigured, but do not have to, and other packages may not assume that they do.

We should decide what happens when an Essential package is also marked as Protected, should we error out, warn, ignore and consider it the strongest of both fields?

Packages must depend on Protected packages like other packages and may not omit those dependencies like they can for Essential.

Alternatives

We have been throwing some ideas around, w/o much consideration, which might or might not be worth considering.

  • It might have been nicer to have Essential state what it was essential for, say the package-manager, boot-system or meta-package, etc. Changing Essential is probably impractical but maybe we could have a new Essential-For field.

  • Overload Priority: required to imply "it cannot be easily removed w/o force", although this means changing the semantics of an established and global token which would be hard to accommodate for backwards compatibility. It also has the problem that currently libraries do have that priority, although this might be solvable with a new Obsoletes field, but that might make transitions more difficult, and shared libraries do need to be able to coexist anyway and should not obsolete their older counterparts.

  • The new Protected field could, instead of being a boolean, be a list of things (such as package states) being protected from, as in "unpacked configured", etc.

Tasks

  • (./) dpkg must not remove Protected packages without a force-remove-protected or similar flag.

  • Add support to frontends:
    • (./) apt

    • cupt

    • smart

    • any other relevant frontend that needs to deal with it.
  • Add definition to Debian Policy. 983304

Use cases

  • site-local system configuration meta packages.

  • Essential-like packages relevant only to some set of systems (for example, anything involved in the boot process).

  • Might be useful to be able to reduce the set of essential packages (things like mount, e2fsprogs and all the libraries they are depend on are currently in the set of things debootstrap has to unpack twice to fulfill the Essential-requirements. If they were only Protected: yes, then the set of packages getting those requirements could be reduced).

See also Proposals/EssentialOnDiet and BusterPriorityRequalification.


CategorySpec