Bug#759491: Defining pseudo-essential
Hi!
On Wed, 2014-08-27 at 09:22:42 -0700, Russ Allbery wrote:
> 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:
> @@ -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>
The way I've always thought and understood pseudo-essential has been
any packages in the set of packages pulled by Essential:yes ones but
not marked as Essential:yes. Because they cannot be removed either,
even with alternatives, you always need at least one.
The second prominent case of pseudo-essential are private dependencies
of an Essential:yes or another pseudo-essential package. The awk case
is actually an exception rather than a common case.
> + <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.
Duped lines.
> + </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>
> +
Not all pseudo-essential packages should be considered to be the same,
awk is an almost Essential pseudo-essential, but only by convention.
Because virtual packages cannot be Essential:yes it just gets pulled
in by base-files, so its functionality is expected to be available to
any other package (w/o an explicit dependency), but most (if not all) of
the rest of pseudo-essential packages are just private implementation
details, and should only be relied on by their direct dependers, like
xz-utils was for a while from dpkg, before it got switched to liblzma.
And as mentioned above that latter case is the actual prevalent common
usage. So, I disagree pseudo-essential packages need not be explicitly
depended on.
> + <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>
The problem is that the Essential field conveys several conflated
meanings and functions.
* It marks packages that are necessary for the system, at installation
_and_ boot time, that's why it's made very hard to remove them.
* It marks packages that are necessary for dpkg to be functional all
the time, even when unpacked during upgrades, but this also applies
for booting even on sudden system crashes and similar.
* It's also used to avoid dependency loops; and because these are
always going to be present, packages can actually get by with not
listing them as direct dependencies (execept when versioned).
The distinction on when a pseudo-essential needs to function as an
Essential:yes package is determined by its depender, so if it's
pulled through Pre-Depends then it should behave as an Essential:yes,
otherwise it'st just a required dependency.
Packages that divert, provide alternatives, etc might need to behave
like an Essential:yes package (to not break the system's expectations),
but I'd not consider them to be pseudo-essential, as long as the
dependency is not initiated by an Essential:yes or a pseudo-essential
package.
Thanks,
Guillem
Reply to: