Bug#994275: Reverting breaking changes in debianutils

[Clint Adams <clint@debian.org>]

On Sat, Oct 16, 2021 at 05:56:17PM +0200, Thorsten Glaser wrote:
> 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 can think of no reason why anyone would need to run `which -a`
from a maintainer script.  For interactive use, csh (and tcsh)
never had -a for `which`.  The reason that zsh has `which -a` is
because it shares code with `whence -a`, which was taken from
ksh in the '80s.  Of course there's no telling whether it would
have evolved later on if it had been originally csh-compatible.

> 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 disagree.  This is not a good system.  This is how you architect an
ultraconservative culture that discourages people from fixing things.

On Sun, Oct 17, 2021 at 06:32:33AM -0400, James Cloos wrote:
> i got hit by the removal of tepfile(1); pv-grub-menu uses it in its
> postint script and its removal started blocking my apt upgrades.  i had
> to copy tempfile over from a virt stuck on an older deb to get around it.
> 
> (cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996101)
> 
> it would be useful to ensure no packages rely on something before
> removing it...

The fix for pv-grub-menu is as follows:

---8<---snip---8<---
diff --git a/update-menu-lst b/update-menu-lst
index f2ca1c7..2e01a39 100755
--- a/update-menu-lst
+++ b/update-menu-lst
@@ -128,7 +128,7 @@ fi
 # Default options to use in a new config file. This will only be used if $menu_file
 # doesn't already exist. Only edit the lines between the two "EOF"s. The others are
 # part of the script.
-newtemplate=$(tempfile)
+newtemplate=$(mktemp)
 cat > "$newtemplate" <<EOF
 # $menu_file_basename - See: grub(8), info grub, update-grub(8)
 #            grub-install(8), grub-floppy(8),
@@ -443,7 +443,7 @@ howmany=$(GetMenuOpt "howmany" "$howmany")
 memtest86=$(GetMenuOpt "memtest86" "$memtest86")
 
 # Generate the menu options we want to insert
-buffer=$(tempfile)
+buffer=$(mktemp)
 echo $start >> $buffer
 echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" >> $buffer
 echo "## by the debian update-grub script except for the default options below" >> $buffer
---8<---snip---8<---

How much effort is involved with that?  I would guess that it is less than
bullying me into adding a `tempfile` as a Debian-specific patch to debianutils
or bullying me into uploading a `tempfile` package that I do not wish to
maintain.

On Sun, Oct 17, 2021 at 05:36:25AM -0700, Felix Lechner wrote:
> Lintian's last remaining reference to 'tempfile' was dropped. [1] The
> updated tag description is now live on our website. [2]

Thanks.

On Sun, Oct 17, 2021 at 02:33:44PM +0100, Wookey wrote:
> I think causing build failures is enough reason to say this. I don't
> suppose that mine is the only one. Yes those builds are buggy and
> should not do this, and we should make efforts to find out why bazel
> (or possibly the build scripts it is operating on) is/are so crappy,
> but for now I agree that reverting this is the right thing to do.
> 
> We have time to do this transition properly and quietly in the
> background, without causing random breakage. A message about a binary
> moving from one package to another does not need to be printed on
> every usage of that binary. Indeed it is actively unhelpful to do so.

Boyuan packaged GNU which and uploaded it to NEW in August.  It is now
October, and neither GNU which nor *BSD which nor any other which
alternative is in unstable.  Presumably one of these could have put
a band-aid on your bazel problem, though of course any version of
`which` might output things to stderr for a variety of reasons.

Lots of things broke between buster and bullseye.  Even in stable,
people are struggling with horrible i915 driver bugs.  Would it have
been reasonable to demand that bullseye's kernel be reverted to Linux
4.19 and kept there for 5-10 years until someone figured out the
drm issues?

My DreamPlug's audio device went from being card0 to card1, breaking
everything expecting it to be card0.  Would it have been reasonable
to revert Linux, ALSA userland, systemd/udev, and whichever other
packages until I found the time to figure out what changed and why?

Is the difference that these packages aren't Essential?  Or that the
bug is within the packages themselves instead of a reverse dependency?
Or that it involves a package build instead of ordinary operation?

On Mon, Oct 18, 2021 at 11:28:52AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 13 Oct 2021, David Bremner wrote:
> There have been other reports of failures due to the message on stderr,
> autopkgtest is not the only one (wookey mentionned a build failure).

GNU which can output things to stderr.  FreeBSD which can output to stderr.
There is no guarantee that cjwatson which won't output anything else to
stderr.

> In any case, a message saying that which is deprecated when in fact
> `which` will stay around (but maintained in another packages) is not
> helpful.

Tell me, what would be helpful?

On Mon, Oct 18, 2021 at 11:50:32AM -0700, Sean Whitton wrote:
> As Raphael has mentioned, it's unlikely that when debianutils' which(1)
> has been replaced with one in another essential or transitively
> essential package that the new which(1), whether it's the same code or
> something else, will print deprecation warnings.  And then it seems odd
> to print them for a while and then stop printing them.

I find this to be a curious statement.  This implies a contract of
future behavior that does not exist.