[10/16] which: update 2.21 -> 2.23

From: Alexander Kanavin <alex@linutronix.de>

This (and 2.22) is a first release in many years.

- drop tweaks and dependency on cwautomacros as that is no longer used

- drop patch as configure.ac has been rewritten

- drop --disable-iberty as otherwise built-in implementation of xmalloc() isn't enabled

Sadly, cwautomacros has been replaced by an equally custom, weird set
of macros, written by 'which' maintainer: https://github.com/CarloWood/cwm4

- one effect of that is that autoreconf isn't happy with which's configure.ac and won't run;
one is supposed to use a custom script instead: https://github.com/CarloWood/cwm4/blob/master/scripts/bootstrap.sh

- alas, that script is not shipped in tarballs; the maintainer wants
everyone to trust their 200k configure script (hello xz backdoor)

- building from git (where the script exists) is not impossible,
but that has no version tags

- so in the end configure.ac is deleted; this has an effect
of autotools.bbclass running configure instead

All this 'special handling' for what, exactly? One single-function
executable, one manpage and one info page, which should all be in coreutils
to begin with. GNU's attachment to autotools defies reason.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../which/which-2.21/automake.patch           | 19 ------------
 ...opt-Fix-signature-of-getenv-function.patch | 29 +++++++++++--------
 .../which/{which_2.21.bb => which_2.23.bb}    |  8 ++---
 3 files changed, 19 insertions(+), 37 deletions(-)
 delete mode 100644 meta/recipes-extended/which/which-2.21/automake.patch
 rename meta/recipes-extended/which/{which-2.21 => which-2.23}/0001-getopt-Fix-signature-of-getenv-function.patch (51%)
 rename meta/recipes-extended/which/{which_2.21.bb => which_2.23.bb} (74%)

On 11 Sep 2025, at 09:51, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote:
> This (and 2.22) is a first release in many years.

Yay!

> - drop tweaks and dependency on cwautomacros as that is no longer used

Yay!

> Sadly, cwautomacros has been replaced by an equally custom, weird set
> of macros, written by 'which' maintainer: https://github.com/CarloWood/cwm4

Okaaaaay

> - one effect of that is that autoreconf isn't happy with which's configure.ac and won't run;
> one is supposed to use a custom script instead: https://github.com/CarloWood/cwm4/blob/master/scripts/bootstrap.sh

Sigh.

> - alas, that script is not shipped in tarballs; the maintainer wants
> everyone to trust their 200k configure script (hello xz backdoor)

Facepalm.

> - building from git (where the script exists) is not impossible,
> but that has no version tags

Groan.

> - so in the end configure.ac is deleted; this has an effect
> of autotools.bbclass running configure instead

Ick.

> All this 'special handling' for what, exactly? One single-function
> executable, one manpage and one info page, which should all be in coreutils
> to begin with. GNU's attachment to autotools defies reason.

The attachment to not even standard autotools, even.

Between various factors including how late in the cycle we are, how ugly this upgrade is, and how minor GNU which is, and the number of post-release “fix out of bounds” patches in master, I propose holding off this for now.

We can file bugs and talk with upstream about some of the pain points (no tags, no rebuilds from tarballs, etc sounds like he’s trying to actively encourage a supply chain attack) and hopefully have a saner release in the future?

Ross

On Mon, 15 Sept 2025 at 21:25, Ross Burton <Ross.Burton@arm.com> wrote:

> > All this 'special handling' for what, exactly? One single-function
> > executable, one manpage and one info page, which should all be in coreutils
> > to begin with. GNU's attachment to autotools defies reason.
>
> The attachment to not even standard autotools, even.
>
> Between various factors including how late in the cycle we are, how ugly this upgrade is, and how minor GNU which is, and the number of post-release “fix out of bounds” patches in master, I propose holding off this for now.
>
> We can file bugs and talk with upstream about some of the pain points (no tags, no rebuilds from tarballs, etc sounds like he’s trying to actively encourage a supply chain attack) and hopefully have a saner release in the future?

Or drop GNU which entirely from core. Alternatives are available in
debianutils (and debian defaults to it) or busybox.

Alex

On Mon, 15 Sept 2025 at 21:25, Ross Burton <Ross.Burton@arm.com> wrote:

> > All this 'special handling' for what, exactly? One single-function
> > executable, one manpage and one info page, which should all be in coreutils
> > to begin with. GNU's attachment to autotools defies reason.
>
> The attachment to not even standard autotools, even.
>
> Between various factors including how late in the cycle we are, how ugly this upgrade is, and how minor GNU which is, and the number of post-release “fix out of bounds” patches in master, I propose holding off this for now.
>
> We can file bugs and talk with upstream about some of the pain points (no tags, no rebuilds from tarballs, etc sounds like he’s trying to actively encourage a supply chain attack) and hopefully have a saner release in the future?

I sat down, wrote and tested a meson.build file for this (in less than
an hour). V2 patches coming soon, but I'm really not sure whether the
maintainer will be open to the idea of throwing away all his precious
m4 macros and replacing them with a 50x shorter meson file. GNU is
known to dismiss anything that is not autotools as 'passing fads'
(I've had this response from gettext maintainer).

Alex