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.
> 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.
Cheers,
--
Bill. <ballo...@debian.org>
Imagine a large red swirl here.
