Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary

[Russ Allbery <rra@debian.org>]

Manoj Srivastava <srivasta@debian.org> writes:

>         I think we can add wording that says that these criteria are
>  useful while trying to decide whether a package should be made
>  Essential or not.  Once it is Essential, then all bets are off, and
>  packages are, in effect, never removed from the set, unless
>  extraordinary effort is undertaken by someone.

Here's a proposed clarification of the current Policy language around
Essential.  Comments, feedback, seconds?

The first part of the diff cuts out of the footnote some things that are
moved into the main Policy text in the second part of the diff.

diff --git a/policy.sgml b/policy.sgml
index c9bd84f..d0dc2dc 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -985,29 +985,23 @@
 	  (see below), and should not do so unless they depend on a
 	  particular version of that package.<footnote>
             <p>
-              Essential is defined as the minimal set of functionality
-              that must be available and usable on the system even
-              when packages are in an unconfigured (but unpacked)
-              state.  This is needed to avoid unresolvable dependency
-              loops on upgrade.  If packages add unnecessary
-              dependencies on packages in this set, the chances that
-              there <strong>will</strong> be an unresolvable
-              dependency loop caused by forcing these Essential
-              packages to be configured first before they need to be
-              is greatly increased.  It also increases the chances
-              that frontends will be unable to
-              <strong>calculate</strong> an upgrade path, even if one
-              exists.
+	      Essential is needed in part to avoid unresolvable dependency
+	      loops on upgrade.  If packages add unnecessary dependencies
+	      on packages in this set, the chances that there
+	      <strong>will</strong> be an unresolvable dependency loop
+	      caused by forcing these Essential packages to be configured
+	      first before they need to be is greatly increased.  It also
+	      increases the chances that frontends will be unable to
+	      <strong>calculate</strong> an upgrade path, even if one
+	      exists.
             </p>
             <p>
-              Also, it's pretty unlikely that functionality from
-              Essential shall ever be removed (which is one reason why
-              care must be taken before adding to the Essential
-              packages set), but <em>packages</em> have been removed
-              from the Essential set when the functionality moved to a
-              different package. So depending on these packages
-              <em>just in case</em> they stop being essential does way
-              more harm than good.
+	      Also, functionality is rarely ever removed from the
+	      Essential set, but <em>packages</em> have been removed from
+	      the Essential set when the functionality moved to a
+	      different package. So depending on these packages <em>just
+	      in case</em> they stop being essential does way more harm
+	      than good.
             </p>
           </footnote>
 	</p>
@@ -1094,10 +1088,13 @@
 	<heading>Essential packages</heading>
 
 	<p>
-	  Some packages are tagged <tt>essential</tt> for a system
-	  using the <tt>Essential</tt> control file field.
-	  The format of the <tt>Essential</tt> control field is
-	  described in <ref id="f-Essential">.
+	  Essential is defined as the minimal set of functionality that
+	  must be available and usable on the system at all times, even
+	  when packages are in an unconfigured (but unpacked) state.
+	  Packages are tagged <tt>essential</tt> for a system using the
+	  <tt>Essential</tt> control file field.  The format of the
+	  <tt>Essential</tt> control field is described in <ref
+	  id="f-Essential">.
 	</p>
 
 	<p>
@@ -1122,6 +1119,19 @@
 	</p>
 
 	<p>
+	  Maintainers should take great care in adding any programs,
+	  interfaces, or functionality to <tt>essential</tt> packages.
+	  Packages may assume that functionality provided by
+	  <tt>essential</tt> packages is always available without
+	  declaring explicit dependencies, which means that removing
+	  functionality from the Essential set is very difficult and is
+	  almost never done.  Any capability added to an
+	  <tt>essential</tt> package therefore creates an obligation to
+	  support that capability as part of the Essential set in
+	  perpetuity.
+	</p>
+
+	<p>
 	  You must not tag any packages <tt>essential</tt> before
 	  this has been discussed on the <tt>debian-devel</tt>
 	  mailing list and a consensus about doing that has been

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>