On Sun, 03 Oct 2021 at 22:09:31 +0000, Clint Adams wrote: > The package description uses the phrases "specific to Debian" and > "installation scripts of Debian packages". The fact that > debianutils is used on non-deb operating systems suggests a failure > at the former.
Given its package description, I too am confused by other distributions having picked up debianutils (as it seems at least Arch and Gentoo have), but the packages found in non-Debian-derived distributions are not under our control. > The fact that 95% of my inbox consists of hatemail > about the interactive usage of `which` suggests a failure at the > latter. I'm sorry you're receiving hatemail about this package, and that's not OK, but it's orthogonal to whether the changes discussed in this bug were the right thing for Debian. > debianutils should consist solely of utilities that are actually > deserving of Essential status, that are maintained by debianutils > upstream, and do not needlessly duplicate functionality provided by > other sources. I was under the impression that debianutils is (intended to be) a Debian-specific package with no separate upstream existence. Does it have releases other than "whatever is in unstable"? Is there an upstream maintainer distinct from its Maintainer and Uploaders, namely you and Manoj? "debianutils should consist of utilities maintained in debianutils" seems slightly circular. Is there an intended scope for what's in debianutils, beyond "things that need to be Essential because they always used to be Essential"? I see that CONTRIBUTING documents some of the utilities in debianutils as being unsupported/pending deprecation, such that if new features are desired, contributors are asked to instead fork the utility and coordinate removal from debianutils (and presumably takeover by a new package, given their Essential status). Can we infer the utilities you want to continue to maintain are everything not on that list? debianutils currently has: - add-shell, remove-shell, update-shells: Debian-specific(?) maintainer-script infrastructure for maintaining /etc/shells, analogous to how init-system-helpers maintains system services. Clearly at least transitively Essential, because if they were a separate package, the Essential dash and bash would depend on them. - ischroot, run-parts, savelog, which (and historically tempfile): these seem more like general-purpose utilities than anything else, and Essential from their wide use without an explicit dependency? Of these, CONTRIBUTING describes ischroot, savelog and which as being unsupported (deprecated or pending deprecation) but presumably run-parts is not in that category? CONTRIBUTING calls out logrotate as being better than savelog, but savelog gets used by Essential packages like dpkg, and I don't think logrotate is necessarily suitable to be transitively Essential. - installkernel: the Debian implementation of an integration hook that is expected to be invoked by the upstream Linux kernel build system, analogous to how LSB init scripts can expect to source /lib/lsb/init-functions and we provide a Debian implementation of that interface in lsb-base? > Divestiture of mktemp, readlink, sensible-editor, sensible-pager, > sensible-browser, tempfile, and possibly mkboot were adjustments > toward a better debianutils. Yes, and in general I think that direction is fine, as long as the transition away from these utilities being in debianutils is done carefully. mktemp and readlink were taken over by Essential coreutils, with a transitional Pre-Depends; sensible-* were moved to non-Essential sensible-utils, with a transitional Depends (making sensible-utils transitively Essential for one release) to ensure existing systems didn't lose them, and presumably some reasonable plan to ensure that dropping them from the Essential set wouldn't break existing packages. mkboot doesn't have a replacement that I know of, but it seems like the sort of utility that had a very limited use by the time it was removed, so I'm happy to trust your judgement on what the appropriate time was to remove it ("your" referring to you and Manoj as a team here - I know it was actually Manoj who removed that one). However, I don't think which(1) and tempfile(1) are really in the same situation as all those. From my point of view, debianutils which(1) has a lot in common with sysvinit-utils pidof(8): if we were defining Essential today, those programs likely wouldn't be in it, and they should probably be used a lot less than they are (in favour of the command builtin and pgrep, respectively); but the fact remains that they *are* in Essential, and too widely-used (by packages with no dependency, because Essential) for a mass-bug-filing to be straightforward. which(1) and tempfile(1) suffer from this somewhat worse than pidof, because "which" is a common English word and "tempfile" is a common name for variables, so locating users of those utilities via codesearch.debian.net (which would normally be step 1 for a mass-bug-filing) is somewhat futile. Despite not being standardized in the same way that the command builtin is, which(1) is also something that is widely expected to exist on Unix systems for historical reasons, so if it was packaged independently I suspect it would have at least Priority: important, based on the "what on earth is going on, where is foo?" criterion in Policy (and regardless of whether it *should* be used so widely). I certainly see it used a lot in upstream build systems, tests and similar scripts, even in situations where `command -v` would have been better. `command -v` is not always a valid substitute for which(1). For example, when Flatpak's test suite builds a tiny container that includes /bin/sh and /usr/bin/echo, it can't use `command -v echo` because that would find shell builtins as higher-precedence than their ordinary executable equivalents. In Flatpak's case, the test happens to be a bash script and so can use `command -P echo` or `type -P echo`, but those are bash-specific and not always available in a POSIX shell. None of this implies that what we might call "debianutils upstream" needs to be responsible for which(1) and tempfile(1) *forever*; but removing functionality from Essential is disruptive, so I think the maintainers of debianutils *in Debian* (in practice the same people?) have a responsibility to ensure that debianutils.deb either continues to provide the Essential functionality of previous versions, or pulls in a version of some transitively-Essential package that takes over the Essential functionality so that it can become someone else's responsibility. To the best of my knowledge, we don't currently have a native package that has the semantics of "contains things that are Essential for historical reasons", unless debianutils is it (which you say it isn't) or unless sysvinit-utils is it (but I don't think it really should be, because that entangles responsibility for a non-default init system with responsibility for Essential utilities, and it isn't clear to me that we should be requiring people who want to work on one of those aspects of src:sysvinit to take responsibility for the other). smcv