Differences between revisions 1 and 16 (spanning 15 versions)
Revision 1 as of 2016-03-05 23:32:52
Size: 581
Comment:
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 1: Line 1:
APT supports an Important field, similar to essential, with the following differences: ## page was renamed from Teams/Dpkg/Spec/ImportantField
Line 3: Line 3:
* Important packages are not required to be installed
* They do not have to be usable while unconfigured
{{{#!wiki caution
 * '''Status:''' draft, experimental
 * '''Supported-Since:''' dpkg 1.20.1, apt 2.1.7 (basic support)
 * '''RFC Thread:''' <<mid(20200309092336.GA15210@gaara.hadrons.org)>>
}}}
Line 6: Line 9:
Or too define it on its own: {{{#!wiki warning
This draft is out-of-sync with the RFC thread proposal and ''/usr/share/doc/dpkg/protected-field.txt'', requires a resync.
}}}
Line 8: Line 13:
Important defines packages that must not be easily removed from the system once installed. For example, an init system might be marked important to not be removed easily from non-container systems. = Introduction =
Line 10: Line 15:
They should supply their core functionality while unconfigured, but do not have to. Packages must depend on Important packages like other packages. 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. /* The problem is that for any package in the boot sequence we do want them to always be usable, otherwise a crash in the wrong place might render the system unbootable. This might not apply to the meta-packages case though. */

== 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. /* Again, I'm not sure this is a great idea. */

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 =

 * (./) DebianPkg:dpkg must not remove '''Protected''' packages without a force-remove-protected or similar flag.
 * Add support to frontends:
   * (./) DebianPkg:apt
   * DebianPkg:cupt
   * DebianPkg:smart
   * any other relevant frontend that needs to deal with it.
 * Add definition to Debian Policy. DebianBug:983304

= Use cases =

 * site-local system configuration meta packages. /* Do these actually require this protection? And if so why? */
 * '''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

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