Bug#994275: Reverting breaking changes in debianutils
On Wed, Oct 06, 2021 at 10:37:25AM +0100, Simon McVittie wrote:
> 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
Yes, one of the many changes that was on hold until the bullseye
release was addressing a (non-deb) downstream request to provide
signed tarballs[0].
> upstream maintainer distinct from its Maintainer and Uploaders, namely
> you and Manoj?
For now it is I.
> "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 think that you may have misparsed my sentence.
> 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?
I would say more that the set of utilities I think should remain in
debianutils for the time being for one reason or another is 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.
It is my hope that update-shells will obsolete add-shell and remove-shell
as well.
> - 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?
run-parts is special in that it is roughly feature-complete and, as
far as I am aware, there are no extant alternatives other than Red
Hat's "fork" of debianutils run-parts as a shell script. I could be
convinced that it shouldn't be Essential though.
ischroot is pretty flawed and I continually regret acquiescing to its
incorporation. savelog is garbage, but is, as you point out, used by
dpkg. which was only important for maintainer scripts when POSIX only
specified alternatives like `type` and `command -v` in optional
extensions. Now which is only important to people using bash, it seems.
> 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.
I don't have an opinion on that, but if dpkg wants to subsume savelog,
that would be fine by me.
> 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.
I can't comment on the reasonableness of the plan, as I had nothing to
do with it.
> `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.
Originally, I avoided specifying a particular alternative in the
deprecation warning because the appropriate substitute does indeed
depend on what the user is trying to do.
> 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.
I think that this (short-term transitively Essential) is fine for
which(1), especially if GNU which is the only which(1) to make it
through NEW within the next year and a half.
However, I don't think that this is reasonable for tempfile(1) unless
someone is actually willing to package and maintain a tempfile(1).
> 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).
I certainly wouldn't want anyone to be required to work on either which(1)
or tempfile(1).
On Mon, Oct 11, 2021 at 10:43:13AM +0200, Sebastian Ramacher wrote:
> I don't consider #992399 to be fixed. I specifically asked for a
> coordinated transition for the tempfile removal in that bug. So far I
> see no indication that this transition is coordinated in any way. As far
I don't know whether to be offended by anyone not seeing things. The
stable version of tempfile(1) prints a deprecation warning. I filed bugs.
I sent patches. All breaking changes were uploaded to unstable at the
beginning of the development cycle so to maximize the available time for
testing. Some people did NMUs.
> I think it would have been easy enough to follow a more systematic
> approach by processing the whole archive with piuparts to detect all the
> remaining cases.
I am not sure that piuparts could detect all cases.
> Additionally, Debian Policy 10.4 and the lintian tag
> possibly-insecure-handling-of-tmp-files-in-maintainer-script still
> recommend "tempfile or mktemp".
These seem like minor bugs in debian-policy and lintian.
> Beyond tempfile(1) in maintainer scripts, random uses of tempfile
> are still being reported. See #995583 for the latest example. But also
> for this case, I see no coordination.
> Helmut has shown how to remove interfaces from the essential set with
> e2fsprogs. But I think e2fsprogs was in a much better place when this
> was done: the interesting interfaces were moved to util-linux and for
> the remaining users of e2fsprogs it was easy enough to add dependencies.
> tempfile(1) however is used in maintainer scripts with the potential for
> upgrade failures. At least for that case I would expect that all the
> users are fixed in release $x and then tempfile could be removed in $x
> + 1.
>
> For all the other uses of tempfile, I'm currently lacking an overview.
While I don't deny that the methodology for which Helmut advocates works,
I do deny that it is the right way to manage changes of this nature.
On Wed, Oct 13, 2021 at 01:05:50PM -0700, Sean Whitton wrote:
> The debianutils package must continue to provide the tempfile(1)
> program until a compatible utility is available in a package that is
> at least transitively essential in Debian 12.
Could you define "a compatible utility"?
[0] https://clint.pages.debian.net/debianutils-tarballs/
Reply to: