Bug#994275: Reverting breaking changes in debianutils
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
Reply to: