On Sun, 24 Oct 2021 19:08:20 +0000 Clint Adams <cl...@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. Hi, 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 /home/tito/bin/sh /bin/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. Ciao, Tito > 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. >
