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.j...@joshtriplett.org> From: Josh Triplett <j...@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