Bug#758234: Defining pseudo-essential
Control: clone 758234 -1
Control: retitle -1 Define pseudo-essential
Ansgar Burchardt <ansgar@debian.org> writes:
> That's related to being (pseudo-)essential and not to priority. Package
> of Priority: required do not have to be pseudo-essential, but packages
> of lower priority can be pseudo-essential:
I hate to clone this bug yet again, but this makes clear to me that Policy
really needs a definition of pseudo-essential. How about this? (Diff is
cut and pasted and therefore won't apply cleanly due to tab damage; I'll
push a branch once the cloned bug has a bug number assigned.)
diff --git a/policy.sgml b/policy.sgml
index 6eac491..85f2389 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1288,7 +1288,9 @@ zope.
unless absolutely necessary. A shared library package
must not be tagged <tt>essential</tt>; dependencies will
prevent its premature removal, and we need to be able to
- remove it when it has been superseded.
+ remove it when it has been superseded. Instead, shared library
+ packages required for essential functionality are treated as
+ pseudo-essential. See <ref id="pseudo-essential">.
</p>
<p>
@@ -1321,6 +1323,76 @@ zope.
mailing list and a consensus about doing that has been
reached.
</p>
+
+ <sect1 id="pseudo-essential">
+ <heading>Pseudo-essential packages</heading>
+
+ <p>
+ Sometimes, specific libraries, commands, or services are
+ essential in the sense that they must be usable at all times,
+ even if not configured, but the package that provides these
+ interfaces may change. The two most common cases are
+ essential shared libraries, which must not be explicitly
+ declared essential so that they can be removed during
+ transitions, or commands and services that can be provided by
+ the user's choice of multiple packages. A typical example of
+ the latter is <prgn>awk</prgn>: the presence of a
+ working <prgn>awk</prgn> command is part of the Essential set,
+ but there are multiple acceptable implementations
+ of <prgn>awk</prgn> that can provide this required command.
+ </p>
+
+ <p>
+ In these cases, the packages that provide implementations of
+ the essential functionality are
+ called <tt>pseudo-essential</tt>. They must not be marked
+ essential via the <tt>Essential</tt> control field, but must
+ still supply all of the functionality defined to be essential
+ even when unconfigured.
+ called <tt>pseudo-essential</tt>. They must not be marked
+ essential via the <tt>Essential</tt> control field, but must
+ still supply all of the functionality defined to be essential
+ even when unconfigured.
+ </p>
+
+ <p>
+ As with essential packages, other packages may assume that the
+ essential functionality provided by pseudo-essential packages
+ is always available without declaring explicit dependencies.
+ However, treat this with caution: only the functionality of
+ the pseudo-essential package that is required to support
+ essential functionality is considered essential. Sometimes,
+ pseudo-essential packages provide a variety of commands or
+ services, only some of which are essential. If there is any
+ doubt about whether specific functionality provided by a
+ pseudo-essential package is essential, it's best to be
+ cautious and add an explicit dependency. As a special case of
+ this rule, all packages must continue to declare explicit
+ dependencies on pseudo-essential shared libraries following
+ the normal rules for shared library dependencies as defined
+ in <ref id="sharedlibs-intradeps">.
+ </p>
+
+ <p>
+ It is unfortunately difficult to determine whether a given
+ package is pseudo-essential. The most common way to identify
+ pseudo-essential packages is to look at packages listed in
+ the <tt>Depends</tt> or <tt>Pre-Depends</tt> control fields of
+ an essential package (or, transitively, as a dependency of
+ another package so listed), but not all of those packages are
+ pseudo-essential. Essential packages may depend on other
+ packages but may not require those packages be usable without
+ being configured to provide the essential functionality, in
+ which case those dependencies do not become pseudo-essential.
+ And packages that divert, provide alternatives for, or
+ otherwise potentially interfere with pseudo-essential packages
+ may themselves be pseudo-essential even though they don't
+ appear in the dependency chain of an essential package.
+ </p>
+
+ <p>
+ Issues involving essential and pseudo-essential packages are
+ often tricky and inobvious. Changes to these packages and
+ their dependencies should generally be reviewed by experienced
+ developers or discussed on <tt>debian-devel</tt>, or both.
+ </p>
+ </sect1>
</sect>
<sect id="maintscripts">
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: