Hi,
continued there with kaol and elbrus.
The term "functional provided by essential packages" leaves room for
interpretation. In fact, what functionality is provided by a package is
a very loosely defined concept in general and that very much is the
reason why our policy still has no definition of what Multi-Arch:
foreign means. The functionality of a package often is quite undefined
unfortunately. Just because you happen to receive some functionality by
depending on a package doesn't mean that you get the same functionality
tomorrow and this fully accounts to implicit dependencies (such as the
ones on essential packages).
A very close example likely is `tar --zstd -c . >/dev/null`. It fails
with `/bin/sh: 1: zstd: not found`. Likewise, tar is essential and zstd
is not. Arguably, tar should suggest or recommend zstd though.
Recommends and Suggests are a mechanism to express optional
dependencies. For instance, diffoscope is a package excessively using
these to avoid hard dependencies. You cannot assume that diffoscope
produces a detailed diff just because your dependencies are satisfied.
It may error out asking you to install another package. gzip suggests
less indicating that some of its functionality is optional and that may
include an entire command.
A better example may be devscripts. It also uses Recommends excessively.
For instance `cvs-debi` fails with `cvs-debi: need the cvs-buildpackage
package installed to run this` and `archpath` fails with
`/usr/bin/archpath: line 30: tla: command not found`.
Neither devscripts or diffoscope are essential, but the underlying
concept is that you can have optional functionality.
The "always available" language refers to another aspect of packaging.
The functionality is normally only required to be available when a
package is configured. If it is deconfigured for upgrading, it may stop
providing its functionality. Not so for essential packages. Their
functionality must remain available even during upgrades.
In essence, I argue that zless is optional functionality and not covered
by the policy text. If it were, we'd quickly find a pile of other policy
violations of the same kind hinting that maybe policy is not up to date
with reality and this actually constitutes a bug in policy.
Splitting quite definitely is an option. I removed e2fsprogs from
essential. It's a lot of work, but it is practically feasible. However,
adding a zless package for a 2kb shell script may not be the best use of
our resources as package metadata produces a cost to every installation.
Paul and kaol pointed out that moving zless to the less package may be
an option though. Given that less implicitly depends on gzip (due to
essential), it would work whenever less is installed.
I'm not convinced that actually constitutes a policy violation, but a
move of zless from gzip to less still sounds plausible to me.
Helmut