Bug#954794: New packages must not declare themselves Essential
Package: debian-policy
Version: 4.5.0.0
Severity: normal
Tags: patch
Previously discussed on the mailing list, which led to a request for
concrete Policy language.
Over the years, "Essential" has made it difficult to reduce installation
size, to reduce chroot/container size, or to coordinate various
transitions. Removing something from the Essential set requires tracking
down every package using it, adding a dependency, carefully managing a
transition across Debian releases, and risking breakage of third-party
packages outside Debian.
Add language to Policy that still allows existing Essential packages to
refactor or transition to different packages (coordinated via
debian-devel) but does not allow new Essential packages.
Also add language that allows packages to declare dependencies on
Essential packages as part of transitions (such dependencies would
previously violate Policy, technically), and soften language that
connects "base system" with "essential".
This change does not propose eliminating the concept of Essential, nor
does it propose that any specific package become non-Essential.
Patch attached; also available at
https://salsa.debian.org/josh-guest/policy/ on the branch
no-new-essential.
- Josh Triplett
>From a4b263709ed183e8b353c669e0e56e225ef8c818 Mon Sep 17 00:00:00 2001
Message-Id: <a4b263709ed183e8b353c669e0e56e225ef8c818.1584974928.git.josh@joshtriplett.org>
From: Josh Triplett <josh@joshtriplett.org>
Date: Mon, 23 Mar 2020 07:11:27 -0700
Subject: [PATCH] New packages must not declare themselves Essential
Over the years, "Essential" has made it difficult to reduce installation
size, to reduce chroot/container size, or to coordinate various
transitions. Removing something from the Essential set requires tracking
down every package using it, adding a dependency, carefully managing a
transition across Debian releases, and risking breakage of third-party
packages outside Debian.
Add language to Policy that still allows existing Essential packages to
refactor or transition to different packages (coordinated via
debian-devel) but does not allow new Essential packages.
Also add language that allows packages to declare dependencies on
Essential packages as part of transitions (such dependencies would
previously violate Policy, technically), and soften language that
connects "base system" with "essential".
This change does not propose eliminating the concept of Essential, nor
does it propose that any specific package become non-Essential.
---
policy/ch-binary.rst | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index 74a1690..ac0623f 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -247,7 +247,9 @@ package.
Packages are not required to declare any dependencies they have on other
packages which are marked ``Essential`` (see below), and should not do
-so unless they depend on a particular version of that package. [#]_
+so unless they depend on a particular version of that package, or unless
+part of a transition to make the ``Essential`` package no longer
+``Essential``. [#]_
Sometimes, unpacking one package requires that another package be first
unpacked *and* configured. In this case, the depending package must
@@ -299,7 +301,7 @@ are allowed to form part of the base system, in order to keep the
required disk usage very small.
The base system consists of all those packages with priority
-``required`` or ``important``. Many of them will be tagged ``essential``
+``required`` or ``important``. Some of them are tagged ``essential``
(see below).
.. _s3.8:
@@ -335,9 +337,14 @@ never done. Any capability added to an ``essential`` package therefore
creates an obligation to support that capability as part of the
Essential set in perpetuity.
-You must not tag any packages ``essential`` before this has been
-discussed on the ``debian-devel`` mailing list and a consensus about
-doing that has been reached.
+New packages must not declare themselves ``essential``, even if this
+requires many other packages to declare explicit dependencies on them.
+Existing ``essential`` packages may continue to use the ``essential``
+flag in new versions. If an existing ``essential`` package needs to
+change its packaging structure in a way that would introduce a new
+package with the ``essential`` flag, this must be discussed on the
+``debian-devel`` mailing list and a consensus and transition strategy
+for doing so must be reached."
.. _s-maintscripts:
--
2.26.0.rc2
Reply to: