Hi, On Sat, 2008-07-05 at 13:50:29 -0700, Russ Allbery wrote: > Here's a proposed clarification of the current Policy language around > Essential. Comments, feedback, seconds? > 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 Seconded. regards, guillem
Attachment:
signature.asc
Description: Digital signature