summaryrefslogtreecommitdiffstats
path: root/doc/protected-field.txt
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-27 09:40:31 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-27 09:40:31 +0000
commitb86570f63e533abcbcb97c2572e0e5732a96307b (patch)
treecabc83be691530ae685c45a8bc7620ccc0e1ebdf /doc/protected-field.txt
parentInitial commit. (diff)
downloaddpkg-b86570f63e533abcbcb97c2572e0e5732a96307b.tar.xz
dpkg-b86570f63e533abcbcb97c2572e0e5732a96307b.zip
Adding upstream version 1.20.13.upstream/1.20.13upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/protected-field.txt')
-rw-r--r--doc/protected-field.txt74
1 files changed, 74 insertions, 0 deletions
diff --git a/doc/protected-field.txt b/doc/protected-field.txt
new file mode 100644
index 0000000..d984440
--- /dev/null
+++ b/doc/protected-field.txt
@@ -0,0 +1,74 @@
+Support for a Protected field
+=============================
+
+Status: draft, experimental
+URL: https://wiki.debian.org/Teams/Dpkg/Spec/ProtectedField
+
+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 is 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 front-ends 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 has 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
+--------
+
+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 front-end,
+ 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 name too confusing 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).