On 09/06/2025 14:55, Bill Allombert wrote: Hello,
On Mon, Jun 09, 2025 at 01:56:21PM +0200, Jerome BENOIT wrote:These executables are not meant to be used from shell as GAP-guava does not install its executables in /usr/bin . By contrast, GAP-nq installs its executable in /usr/bin, so GAP-nq has a different scheme. So the guava executable have their place inside the /usr/libexec/ hierarchy indeed. However, they are architecture dependent, so they have their place inside a triplet hierarchy: if a user runs gap along a given architecture, they expects the involved architecture dependent binaries to belong to the same architecture: the outputs are meant to be the same indeed, but for any reason they can be different.There is no such expectation. If you run x86-sh on a amd64-coreutils system, 'ls' will run the amd64 binary, not the 32-bit binary.
I would not compare the stability of ls(1) with the stability of the executables provided by gap-guava. Having said that, as a scientist, I would expect the behavior that I described.
Why do you need to deviate from the Debian policy ?Where does policy mandates /usr/libexec/<triplet> ? $apt-file -l search /usr/libexec/x86_64-linux-gnu|wc 9 9 106 $seventeen - ~#apt-file -l search /usr/libexec|wc 465 465 6538 So overwhelmingly, /usr/libexec/<triplet> is not used.
My argument is based on the executable-in-usr-lib lintian tag [1]: ==================8><-------------------------------------------------------------------------------- The package ships an executable file in /usr/lib. Please move the file to /usr/libexec. With policy revision 4.1.5, Debian adopted the Filesystem Hierarchy Specification (FHS) version 3.0. The FHS 3.0 describes /usr/libexec. Please use that location for executables. [...] -----------------------><8=========================================================================== So my understanding is that executables in /usr/lib/<archtriplet>/<package>/bin might be moved to /usr/libexec/<archtriplet>/<package> . The former is widely used: # apt-file find /lib/x86_64-linux-gnu | grep '/bin/' | wc -l gives on Sid 2576 Furthermore the final `bin' may not be present, so this number must be larger.I acknowledge that /usr/libexec/<archtriplet> is not often mention in the main policy document.
So far I can remember, this tag is relatively recent. And since its severity is pedantic, package maintainers may not bother to make the move. Whatever, this does not affect the present issue. This might explain that. In final I think that this tag needs to be clarified. I am considering the submit a bugreport. Meanwhile I am also considering to write wrapper instead. Cheers, Jerome
Cheers,
[1] -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
OpenPGP_signature.asc
Description: OpenPGP digital signature
