Hi ladies and gentelhackers!

A lot of packages Build-Depend on valgrind, in order to run checks for
memory leaks, data races and what not during the testsuite. Alas, valgrind
is not available on some architectures, even release (armel) or want-to-be- release (riscv64). Keeping the list current requires watching the valgrind package, and not just the list it declares but archs where it actually
builds on (not x32...) and works (as of today all, but that wasn't always
the case).

You can now replace that list by:
Build-Depends: valgrind-if-available
or preferably:
Build-Depends: valgrind-if-available <!nocheck>
If you want to temporarily exclude an arch please do that with:
Build-Depends: valgrind-if-available [!zx-spectrum !pdp11]
instead of repeating the whole valgrind list.

Getting the list wrong results either in:
* failing to build on some archs, see eg.
https://buildd.debian.org/status/package.php?p=libdnf
* not running valgrind tests, letting bugs slide

And most packages get it wrong; the counts are:
7 valgrind [amd64 arm64 armhf i386 mips mips64el mipsel powerpc ppc64 ppc64el s390x]
5 valgrind
3 valgrind [amd64 i386 powerpc]
2 valgrind [amd64 i386]
2 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] 2 valgrind [!riscv64]
2 valgrind <!nocheck>
1 valgrind-mpi [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64]
1 valgrind [i386 amd64 powerpc armhf]
1 valgrind [amd64]
1 valgrind [amd64 i386] <!nocheck>
1 valgrind [amd64 i386 armhf arm64] <!noinsttest>
1 valgrind [amd64 armhf i386 mips mipsel powerpc s390x]
1 valgrind [amd64 armhf arm64 i386 mips64el mipsel ppc64 ppc64el s390x]
1 valgrind [amd64 arm64 armhf i386 ppc64el s390x powerpc ppc64] <!nocheck>
1 valgrind [amd64 arm64 armhf i386 powerpc ppc64el x32]
1 valgrind [amd64 arm64 armhf i386 powerpc ppc64 ppc64el s390x] <!nocheck>
1 valgrind [amd64 arm64 armhf i386 mipsel mips64el powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x]
1 valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64 x32]
1 valgrind [amd64 arm64 armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x] 1 valgrind [amd64 arm64 armhf i386 mips64 mips64el mips mipsel powerpc ppc64 ppc64el s390x]
1 valgrind [amd64 arm64 armhf i386 mips mipsel mips64 mips64el powerpc ppc64 ppc64el s390x x32]
1 valgrind [amd64 arm64 armhf i386 mips mips64el powerpc ppc64el s390x] <!nocheck>
1 valgrind [amd64 arm64 armhf i386 mips mips64 powerpc ppc64 ppc64el s390x] <!nocheck>
1 valgrind [amd64 arm64 armhf i386 mips mips64 mips64el mipsel powerpc ppc64 ppc64el s390x]
1 valgrind [!riscv64], valgrind (>= 1:3.15.0) [arm64]
1 valgrind [!ia64 !riscv64 !x32 !mips !sparc64 !sh4 !ppc64 !powerpcspe !hppa !alpha !mips64el !armhf !armel !mipsel !m68k]
1 valgrind [!arm64 !ppc64el !armel !alpha !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !m68k !powerpcspe !sh4 !sparc64 !x32]
1 valgrind [!arm64 !ppc64el !armel !alpha !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !m68k !powerpcspe !sh4 !sparc64 !x32 !ia64 !riscv64]

The correct answer currently is:
[amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64]
but it keeps changing, and you don't want to track it by hand if I can do
that for you.

Thus: please [b-]depend on valgrind-if-available.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver!
⠈⠳⣄⠀⠀⠀⠀

"Adam C. Powell, IV" <hazelsct@debian.org>
mpich (U)
petsc (U)
slepc (U)

Adam Borowski <kilobyte@angband.pl>
libpmemobj-cpp
pmdk
pmemkv
vmemcache

Alastair McKinstry <mckinstry@debian.org>
mpich (U)

Andreas Boll <aboll@debian.org>
libdrm (U)
mesa (U)

Andreas Tille <tille@debian.org>
pyutilib (U)

Andres Salomon <dilinger@debian.org>
chromium (U)

Anton Gladky <gladk@debian.org>
dyssol (U)
sundials (U)

Ayatana Packagers <pkg-ayatana-devel@lists.alioth.debian.org>
xorg-gtest

Benjamin Drung <benjamin.drung@ionos.com>
rdma-core

Bernd Zeimetz <bzed@debian.org>
ceph (U)

Ceph Packaging Team <team+ceph@tracker.debian.org>
ceph

ChangZhuo Chen (陳昌倬) <czchen@debian.org>
jq

Christophe Trophime <christophe.trophime@lncmi.cnrs.fr>
freefem++ (U)
getdp (U)

Christopher James Halse Rogers <raof@ubuntu.com>
mir (U)

Debian Bridges Team <team+bridges@tracker.debian.org>
libbloom

Debian Chromium Team <chromium@packages.debian.org>
chromium

Debian EFI <debian-efi@lists.debian.org>
fwupd

Debian GCC Maintainers <debian-gcc@lists.debian.org>
libabigail

Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
gnome-software

Debian GSS Team <help-gss@gnu.org>
gss

Debian Mir Team <team+mir@tracker.debian.org>
mir

Debian Multimedia Maintainers <debian-multimedia@lists.debian.org>
kodi

Debian Octave Group <team+pkg-octave-team@tracker.debian.org>
octave

Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
libfurl-perl
libtest-valgrind-perl

Debian Python Modules Team <python-modules-team@lists.alioth.debian.org>
pyutilib

Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
qtmir (U)

Debian Remote Maintainers <debian-remote@lists.debian.org>
arctica-greeter

Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>
cthreadpool
deal.ii
dyssol
freefem++
mpich
petsc
petsc4py
slepc
slepc4py

Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>
dolfin
fenics-dolfinx
fenicsx-performance-tests
getdp
mshr
sundials

Debian Shishi Team <help-shishi@gnu.org>
shishi

Debian UBports Team <team+ubports@tracker.debian.org>
mir (U)
qtmir

Debian X Strike Force <debian-x@lists.debian.org>
libdrm
mesa
xserver-xorg-video-intel

Debichem Team <debichem-devel@lists.alioth.debian.org>
opendrop

Dima Kogan <dkogan@debian.org>
sundials (U)

Dimitrios Eftaxiopoulos <eftaxi12@otenet.gr>
freefem++ (U)

Drew Parsons <dparsons@debian.org>
dolfin (U)
fenics-dolfinx (U)
fenicsx-performance-tests (U)
mshr (U)
opendrop (U)
petsc (U)
petsc4py (U)
slepc (U)
slepc4py (U)
xserver-xorg-video-intel (U)

Felix Geyer <fgeyer@debian.org>
libseccomp (U)

Florian Schlichting <fschlich@zedat.fu-berlin.de>
libtest-valgrind-perl (U)

Francis Murtagh <francis.murtagh@arm.com>
armnn

Francois Mazen <francois@mzf.fr>
freefem++ (U)

Frédéric Pierret <frederic.pierret@qubes-os.org>
libdnf (U)

Gabriele N. Tornetta <phoenix1987@gmail.com>
austin

Gaudenz Steinlin <gaudenz@debian.org>
ceph (U)

Georges Khaznadar <georgesk@debian.org>
aseba

Graham Inggs <ginggs@debian.org>
deal.ii (U)

gregor herrmann <gregoa@debian.org>
libtest-valgrind-perl (U)

Gunnar Hjalmarsson <gunnarhj@debian.org>
gnome-software (U)

Héctor Orón Martínez <zumbi@debian.org>
device-tree-compiler

James Page <jamespage@debian.org>
ceph (U)

James Tocknell <aragilar@gmail.com>
sundials (U)

Jeremy Bicha <jbicha@debian.org>
gnome-software (U)

Jeroen van der Heijden <jeroen@transceptor.technology>
siridb-server (U)

Johannes Ring <johannr@simula.no>
dolfin (U)
mshr (U)

Jonas Smedegaard <dr@jones.dk>
abiword
libfurl-perl (U)

Jussi Pakkanen <jpakkane@gmail.com>
meson

Kees Cook <kees@debian.org>
libseccomp

Laurent Bigonville <bigon@debian.org>
gnome-software (U)

Loic Minier <lool@dooz.org>
dbus (U)

Luca Bruno <lucab@debian.org>
libseccomp (U)

Mario Limonciello <superm1@gmail.com>
fwupd (U)

Marius Gripsgard <marius@ubports.com>
mir (U)

Martin Quinson <mquinson@debian.org>
simgrid

Mathieu Malaterre <malat@debian.org>
dumpasn1

Matthias Klose <doko@debian.org>
libabigail (U)

Matthias Klumpp <mak@debian.org>
fwupd (U)
gnome-software (U)

Matthias Maier <tamiko+DEBIAN@kyomu.43-1.org>
deal.ii (U)

maximilian attems <maks@debian.org>
xserver-xorg-video-intel (U)

Michael Biebl <biebl@debian.org>
dbus (U)

Michael Gilbert <mgilbert@debian.org>
chromium (U)

Michael Stapelberg <stapelberg@debian.org>
xserver-xorg-video-intel (U)

Michel Le Bihan <michel@lebihan.pl>
chromium (U)

Mihai Moldovan <ionic@ionic.de>
libdnf

Mike Gabriel <sunweaver@debian.org>
arctica-greeter (U)
libdbusmenu (U)
mir (U)
qtmir (U)
xorg-gtest (U)

Paul Gevers <elbrus@debian.org>
siridb-server (U)

Rafael Laboissière <rafael@debian.org>
octave (U)

Riku Voipio <riku.voipio@linaro.org>
chromium (U)
device-tree-compiler (U)

Robbie Harwood (frozencemetery) <rharwood@club.cc.cmu.edu>
gssproxy

Roger Shimizu <rosh@debian.org>
libbloom (U)

Russ Allbery <rra@debian.org>
gss (U)
shishi (U)

Samuel Thibault <sthibault@debian.org>
hwloc
starpu

Sebastian Dröge <slomo@debian.org>
dbus (U)

Simon Josefsson <simon@josefsson.org>
gss (U)
shishi (U)

Simon McVittie <smcv@debian.org>
dbus (U)

Simon Quigley <tsimonq2@debian.org>
mir (U)

SiriDB Maintainers <team+debian-siridb-packaging-team@tracker.debian.org>
siridb-server

Sjoerd Simons <sjoerd@debian.org>
dbus (U)

Stefano Rivera <stefanor@debian.org>
pypy
pypy3

Steffen Moeller <moeller@debian.org>
cthreadpool (U)
pyutilib (U)

Steve McIntyre <93sam@debian.org>
fwupd (U)

Stuart Prescott <stuart@debian.org>
opendrop (U)

Sébastien Villemot <sebastien@debian.org>
octave (U)

The Ayatana Packagers <pkg-ayatana-devel@lists.alioth.debian.org>
libdbusmenu

Thomas Goirand <zigo@debian.org>
ceph (U)

Timo Aaltonen <tjaalton@debian.org>
gssproxy (U)

Torquil Macdonald Sørensen <torquil@gmail.com>
mpich (U)

Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
dbus

Vagrant Cascadian <vagrant@debian.org>
device-tree-compiler (U)

Vasyl Gello <vasek.gello@gmail.com>
kodi (U)

Vincent Cheng <vcheng@debian.org>
xserver-xorg-video-intel (U)

Wookey <wookey@debian.org>
armnn (U)

Євгеній Мещеряков <eugen@debian.org>
diod

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski <kilobyte@angband.pl> wrote:

The correct answer currently is:
[amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64]
but it keeps changing, and you don't want to track it by hand if I can do that for you.

Thus: please [b-]depend on valgrind-if-available.

Do you have any suggestions on how to handle this when the valgrind
test is set by a configure flag?

The way I've been handling it is to just keep a hard-coded list of
valgrind architectures in sync between my debian/control and
debian/rules.

Thank you,
Jeremy Bicha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Feb 20, 2022 at 04:32:43PM -0500, Jeremy Bicha wrote:

On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski <kilobyte@angband.pl> wrote:

The correct answer currently is:
[amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] but it keeps changing, and you don't want to track it by hand if I can do that for you.

Thus: please [b-]depend on valgrind-if-available.

Do you have any suggestions on how to handle this when the valgrind
test is set by a configure flag?

Is the configure flag required to enable valgrind tests? If not, the very point of "configure" scripts is to auto-detect presence of tools.

The way I've been handling it is to just keep a hard-coded list of
valgrind architectures in sync between my debian/control and
debian/rules.

if which valgrind >/dev/null; then


Meow!
--
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢠⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities. -- whitroth on /.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-02-20 at 19:45 +0100, Adam Borowski wrote:

A lot of packages Build-Depend on valgrind, in order to run checks for
memory leaks, data races and what not during the testsuite.  Alas, valgrind is not available on some architectures, even release (armel) or want-to-be- release (riscv64).  Keeping the list current requires watching the valgrind package, and not just the list it declares but archs where it actually
builds on (not x32...) and works (as of today all, but that wasn't always
the case).

This problem seems like one that will continue to happen as people add
valgrind to their build-deps, so I wonder if this should be a lintian
check and a Debian Janitor fixer rather than a once-off MBF.

You can now replace that list by:
    Build-Depends: valgrind-if-available

I wonder if there could be a better way to do this, perhaps the
valgrind package should be available on all arches but empty on the
ones where valgrind isn't available or doesn't work? Alternatively,
perhaps the valgrind-if-available binary package should get merged into
the valgrind source package for ease of keeping the arches in sync?

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmITJPkACgkQMRa6Xp/6 aaMCuA/9GzP5ep5DYKqypNIPumJvkEqRC7XYxI5iyfG73NbsWDuDgPQZcFcjBm6U 39Nrhm8/KLpZK/aUEnmpqpqx82gza7xSPBqsUpqUuKbLugAiEf+fK38bxa8gZGHK gPkZVoZzpkysIA/2n6m+W/r5VQOqY1ow3olh3yegkIaFWPIIa0GKdCn1PphniSVa sVw7LjTYmoiNgwfbLBSI/beqZCpLQyTrSpk7z3fKFYA1KTju1gHAajmzk9Kf+Gvz ZEeZzLmdfGTnKPTotxGtG2SmKlKbAd+rmPg96H9EMgqVtnVGhw2TA0RidHFtvvdh Ma7JRH7dywk81njQLF0utgV36TVbOgzikKVSEAr8WCfylLvGdSWbEISRq9D079Fy MPQXHPZSBAn6TSfffKzH3WtUn5MYZ+v7HiizbKaZrfb8KN/phjnHsctN+UsMYGg7 9R13eTBpp+qjEVQZSjyYSc5mH+JfRVl4Eovwbo0bzMAnQfgM7Q64aDuxNwuDSVwt ZZrjAUzyAWU/lidvdpcOpZlqoBL9JQ/w8tXQhGxgB8ZZl/ErhHTn4vXACD1CLJTP Xckthl99Y+2uI5thksNS16mvOMaXLpPukg0IgE0MrMNAybJnx/aTD2kWf1S4QVQh qw7jE4tfstTUiVq/sEIglbFQrJnELvKiQS/M3qeJAJwsR/tMesc=
=gH0c
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-02-20 at 22:43 +0100, Adam Borowski wrote:

On Sun, Feb 20, 2022 at 04:32:43PM -0500, Jeremy Bicha wrote:

On Sun, Feb 20, 2022 at 1:46 PM Adam Borowski <kilobyte@angband.pl> wrote:

The correct answer currently is:
[amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64] but it keeps changing, and you don't want to track it by hand if I can do that for you.

Thus: please [b-]depend on valgrind-if-available.

Do you have any suggestions on how to handle this when the valgrind
test is set by a configure flag?

Is the configure flag required to enable valgrind tests? If not, the very point of "configure" scripts is to auto-detect presence of tools.

The way I've been handling it is to just keep a hard-coded list of
valgrind architectures in sync between my debian/control and
debian/rules.

if which valgrind >/dev/null; then

This should use "command -v", not which, I think?

Ben.

--
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmIayJEACgkQ57/I7JWG EQl8lBAAxlYrmgVugxUtw27/pI0FvKs1CNzYB8jEWDPlmg4CZuXPvCJevH0iWGNd ZgFkK6Hc6b5uHLTxOikh9hqXnlG2nTkPqxR7bBHZz3Di85z/R5huJjqsik366ggx wT47SY8NBM548+p+xNj0t9bDkHj4MhVaxGVaQIIkhuq63050YEqZrzUYgeJB4GUW EWtveuSQ5RdtoBaMKs0F6LUeq+zqD4eL7vahzvMB2b725CGup24NdXIfx7XUmu8E 0OBmgo4oVzZTbKzejdTqPgLCd5THcFtlTvrHsk9kC0/cVr4zuq/frFd1S9UZ3DdH Hm/YVT+DTKm6w5WGQEt1zYsLd6LX7ljrUximcmexf+NYR/tZTzhJfIR/RdMV1vbi Md+FPYEW1zh4hV7jdkGUyF2zAkipU/kNiWuYF+IB42jZZxOov0vzTPIheeOznJRl ZFHxucx2WULhoFaLkeAxqcT+vpie2+j/ujKEB/Nu9AEgQrfxyKLIzUpoadWIvFd0 PWWQf7IDUS2VfWf2ZtM/h7QUsmOn+fzBKOI+gHy+M7BjQqrlA8/0HB7nxMZ5onzZ +vCQWs4Ee5xe5ULGU8XB2wOpFyaBBJcoFOBsUO/Tm6MahhWSxg4fZuiRyGK1CZG+ Ubzg1j/U3KuGlyf78Ov5ewSV8WGMHI6ry1irz/pzkzFZy/V6AJg=
=TQQL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote:

On Sun, 2022-02-20 at 22:43 +0100, Adam Borowski wrote:

if which valgrind >/dev/null; then

This should use "command -v", not which, I think?

No, and the recent debacle revealed enough reasons that I'm pondering a MBF
to change that _back_ in packages which followed the bad advice.

Among others, "command -v"
* gets confused by aliases
* it fails to check +x perm both in dash and bash. While this is something
required by POSIX, neither shell in unstable checks that, reporting the
command as executable if it's not.
* built-ins get reported as available. And busybox has even "dpkg"
built-in, with a pretty bad implementation.
while the only reason to migrate was:
* one less tool to maintain


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ 'Russkiy voyennyi korabl, idi nakhuy'
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄⠀⠀⠀⠀

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Feb 27, 2022 at 03:40:09AM +0100, Adam Borowski wrote:

No, and the recent debacle revealed enough reasons that I'm pondering a MBF to change that _back_ in packages which followed the bad advice.

do you have a # as a starter?


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Alles weird gut.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmIa8SEACgkQCRq4Vgaa qhyqHw/9ElnlLQP2rR0WmRUGaPSUG+ilmcozj1lTN5iHFwZKy2poZNh/Lt74luli PvZO86EFvRt6NoWTtME+UMc5Tm+LKgwdjLXjJdKk7bQokNnq64fo4QGaOCu21/up YD66x5ZSNU8u6AfIKb1ACh0lsEyU0GoSkpNG4qAOiWOsywQnoynEjdK8gBllJ610 vZUNIhHjPbxcWVB7NOdyzt5/q1rV+wHFffV3AAy+q8wUEY63rSseqlsiQC5cgaVi iSi+d0w8dhijGHPDpNANRyjrZBgbbiiDBPEPOEbYG4gOZZu76i81BHD3ADZERPtq kdkT1N4a+rT2SJB9AC4ZgBG3uzvTGbQO7uVArC88iOuCskBpwhCVwcHUsS6nWLbX vWgvZsWqegsAf6IDrotcylyysVroydDmB75RPx9xifUwJSj/5uTHU+wqgbVkznBo caIkzWtk23Wy1yJgJ6Ak8+0+FGqPjabc0TA0lQbkZYQMViRmcO3a6FNKwU+W6nOt lVeKBFvAT+OPuOkVYT+uvDhseIk45UMOoDhuUmB5OxQIzLpJsAqG52Dm1olGvLwi 8RJI+fG/jdUnnFbUL92aP8ghJ6P3AIag9FPzHJQz67wL5N9l+847Ig7ldvGlS9AP N5UB5IOEP8NdQEnu8hLkKhbtLCM/BGgi72XSI0JnM381jeUTabg=
=rlLV
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-02-27 Adam Borowski <kilobyte@angband.pl> wrote:

On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote:

[...]

This should use "command -v", not which, I think?

No, and the recent debacle revealed enough reasons that I'm pondering a MBF to change that _back_ in packages which followed the bad advice.

Among others, "command -v"
* gets confused by aliases
* it fails to check +x perm both in dash and bash. While this is something
required by POSIX, neither shell in unstable checks that, reporting the
command as executable if it's not.
* built-ins get reported as available. And busybox has even "dpkg"
built-in, with a pretty bad implementation.

[...]

Hello,

Is any of this relevant in the context Debian package building
(especially by autobuilders)? The only thing I can see is if $developer
had a nonexec ~/bin/somecommand and wondered why the local behavior
differed from the autobuilders. Aliases are a non-issue. Built-ins
(like command -v) actually are available, and when the respective
command is called the builtin will be used.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-02-27 at 03:40 +0100, Adam Borowski wrote:

Among others, "command -v"

[...]

* built-ins get reported as available.  And busybox has even "dpkg"
built-in, with a pretty bad implementation.

Like this?

+---
| % which which
| which: shell built-in command
+---

I suggest to implement a new utility named
`/usr/bin/posix-which2` utility if you do not want that ;-)
(Only after proper standardization of course.)

Ansgar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)