Bug#759491: Defining pseudo-essential
Guillem Jover <guillem@debian.org> writes:
> On Wed, 2014-08-27 at 09:22:42 -0700, Russ Allbery wrote:
>> @@ -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.
Hm. One of the points of this wording is to actually agree on a
definition of pseudo-essential. I think it would be more useful if we
could reserve "pseudo-essential" for packages that provide essential
functionality but cannot be marked as essential due to one of the various
limitations in how that field works.
For the other packages that are dependencies of essential packages, maybe
we should just use that: "dependencies of essential packages." Although
I'm not sure why we shouldn't declare some of those packages
pseudo-essential and keep their functionality in the essential set.
> 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.
The problem, of course, is that we have good no mechanism to detect the
missing dependencies on these packages, so in practice the dependencies
tend to get dropped, and they end up as pseudo-essential.
>> + 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.
Yeah, that was from cut and paste. Sorry about that.
> Not all pseudo-essential packages should be considered to be the same,
> awk is an almost Essential pseudo-essential, but only by convention.
I was considering whether we should explicitly list the packages, like
awk, that can be assumed and don't have to be depended on, but I'm not
sure that makes sense to do. Although if it's only awk, we could just do
that.
> 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.
Do you think we should just say that all pseudo-essential packages another
package uses must have a declared explicit dependency except awk, which is
a special case? I could do that.
> 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.
Ah, that's a good distinction. Is that reliable? Can I say that only
Pre-Depends from an essential package creates a pseudo-essential package,
but not a straight Depends? (I think that makes libc6 not
pseudo-essential, since I think it's just Depends, but I'm not positive.)
> 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.
Well, the reason why I wanted to include them in the pseudo-essential set
is that they're required to have that same "works properly even if not
configured" behavior. That is pretty much the defining characteristic of
pseudo-essential, isn't it? (Particularly if we say that packages are
required to depend on pseudo-essential packages they use.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: