[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#994275: Reverting breaking changes in debianutils

On Sun, 24 Oct 2021 19:08:20 +0000
Clint Adams <clint@debian.org> wrote:

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

there is busybox that has which compiled in and is available
in all repos :

$busybox which
BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) multi-call binary.

Usage: which [COMMAND]...

Locate a COMMAND

and It does have command line option -a 

	getopt32(argv, "^" "a" "\0" "-1"/*at least one arg*/);

even if the help says nothing about it.

busybox which -a sh
It is possible to create a single command package if somebody
will maintain it ( e.g busybox-which) like it was done for busybox-syslogd.
tempfile is missing tough.

Hope this helps.


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

Reply to: