Hi, On Thu, Oct 24, 2024 at 10:12:12PM -0500, Aaron Rainbolt wrote: > gzip is a package with priority "essential". It currently suggests the > "less" package, which has priority "important". less is a hard > dependency of zless - if it is not installed, zless will error out with > "exec: less: not found". Section 3.8 of the Debian Policy Manual states > "Packages may assume that functionality provided by essential packages > is always available without declaring explicit dependencies...". This > implies to me that essential packages must be fully functional in all > respects without the installation of any additional dependencies beyond > what the package itself declares, since this is the only way this > assumption can hold true.
This bug was originally reported to #debian-devel and discussion 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. > Either gzip should promote "less" to a dependency, or zless should be > split into a separate package that is not marked as essential. Given > that zless is already part of gzip's functionality, I do not believe > that splitting it out is an option because "any capability added to an > essential package ... creates an obligation to support that capability > as part of the Essential set in perpetuity." 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
