Bug#994275: Reverting breaking changes in debianutils

[Thorsten Glaser]

On Sat, 16 Oct 2021, Clint Adams wrote:

> It is my hope that update-shells will obsolete add-shell and remove-shell

Huh, what’s update-shells?

Hm, apparently something new in sid. Ouch. If you really wish for
that, it’ll involve painful versioned Pre-Depends and a largish
diff for backports :/ and, I think, at least one release in which
both are present so removing a shell in a partial upgrade won’t
fail, aborting dpkg…

> 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.

run-parts is used a lot, though, as it’s rather useful.

> ischroot is pretty flawed and I continually regret acquiescing to its

Huh? -v please. I use that for some decisions on $orkplace systems.

> 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.

No. You’re conflating “which <cmd>”, which indeed is mostly redundant
with “command -v”, with “which -a <cmd>”, which is NOT otherwise
available, and a very useful thing to have, and one which (heh, pun
not intended) I pretty much expect to exist on a system.

> 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.

Hmmh. I personally don’t care too much which which is there, as long
as it’ll support the two(!) common uses, though ofc I’d prefer BSD ☻
but having just one is perhaps less error-prone.

> 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 know that feeling… some package maintainers don’t seem to care about
warnings. But as something in an Essential package I fear it’s up to
you to ping them, time and time again, until they don’t depend on it
any more, instead of proactively removing it.

(I even have to support dashisms in mksh-as-/bin/sh (the lksh binary,
actually) because some bugs are so widespread…)

> These seem like minor bugs in debian-policy and lintian.

ACK.

> > 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.

Indeed.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************