doc/spec/protected-field.txt

   1 Support for a Protected field
   2 =============================
   3
   4 Status: draft, experimental
   5 URL: https://wiki.debian.org/Teams/Dpkg/Spec/ProtectedField
   6
   7 Summary
   8 -------
   9
  10 The goal of the following proposal is to standardize a field to split
  11 part of the «Essential» packages, and add support for it in the package
  12 management stack. There is currently an Important field, that has the
  13 correct semantics but has a very confusing name and is only supported
  14 by apt anyway, so this new field would phase out that one.
  15
  16 Background
  17 ----------
  18
  19 Our current use of «Essential: yes» is confused, and it includes several
  20 conflated things, some of which would be worth splitting up.
  21
  22 We use «Essential» to:
  23
  24   * Denote that a package must be always installed and cannot be
  25     removed (easily), because it is essential to the system in some way.
  26   * Denote that a package must be functional even when just unpacked
  27     (after having been configured once / fully bootstrapped).
  28   * Mark auto-vivification, by making front-ends either complain very
  29     loudly or reinstalling these packages when missing.
  30   * Minimize dependency loops, by making these dependencies implicit.
  31
  32 One problem is that the first point above includes being essential for
  33 the packaging system during upgrades/installation, for the operation
  34 of the system in general, and for the operation of the system during
  35 boot.
  36
  37 The latter is not always necessary though, for example within a chroot,
  38 or some types of containers. There has been work on trying to trim down
  39 the pseudo-essential set as can be seen from:
  40
  41   <https://wiki.debian.org/Proposals/EssentialOnDiet>
  42   <https://wiki.debian.org/BusterPriorityRequalification>
  43
  44 And several of these switches made use of a pre-existing field called
  45 «Important», defined and currently only supported by apt, which had the
  46 following properties:
  47
  48   * These packages are not required to be installed.
  49   * They do not have to be usable while unconfigured.
  50   * Dependencies need to be spelled out.
  51
  52 Proposal
  53 --------
  54
  55 The proposal would be to add support for a new Protected field, with the
  56 following properties:
  57
  58   * Protected packages should not be trivial to remove (require a force
  59     option for example, like «Essential»).
  60   * Protected packages should not be required to be installed (i.e. once
  61     removed they should not be automatically brought back by a front-end,
  62     unlike «Essential»).
  63   * Protected packages must be depended on explicitly (unlike «Essential»).
  64   * Protected packages must be functional even when unpacked (think of
  65     a boot loader or an init system; like «Essential»). [XXX: This one is
  66     not entirely clear and might not match reality anyway, for example kernels,
  67     which might require building an initramfs, etc.]
  68
  69 This would make it possible to phase out the current «Important» field
  70 usage (because it has a name too confusing relative to the «Priority»
  71 value; and has small tooling coverage) and the usage of «Essential» for
  72 at least packages involved in the boot process, and perhaps also for
  73 packages essential for operation of the system in general (in contrast
  74 to packages required for the packaging system).