Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7

[Jerome BENOIT]

Hi,

On 09/06/2025 17:47, Bill Allombert wrote:

On Mon, Jun 09, 2025 at 04:44:21PM +0200, Jerome BENOIT wrote:

==================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> .

No they should be moved to /usr/libexec/<package>.

This would be a regression.

Neither the FHS nor Debian policy define /usr/libexec/<triplet>.

They do not forbid it either.

When multiarch was designed, it was decided multiarch would only cover
/lib and not /bin.

And yet GAP put its own arch-tuple under /bin , which is itself under the 
/usr/share/ hierarchy.

Furthermore, however, executables in /usr/lib/<archtriplet>/<package>/bin may 
move under a multiarch hierarchy
under /usr/libexec otherwise it is a regression.

I would rather say that this tag and the policy related to it must be clarified.

The problem with your approach is that it leads to all binaries in /usr/bin/ to
be moved to /usr/libexec/<triplet>/<package> and a wrapper script added to
/usr/bin/.

Indeed, the problem with the only /bin approach is that it no architecture 
dependent.
The wrapper is an alternative to my patch.
As a scientist, I want to be certain of the architecture against which the 
executables were built.

# apt-file  find /lib/x86_64-linux-gnu | grep '/bin/' | wc -l
gives on Sid
2576

You are counting packages multiple time. Consider

I am counting binaries one time.

Second, counting does not make a rational.

% apt-file  find /lib/ | grep '/bin/' |cut -d: -f1|sort -u|wc -l
439
vs
% apt-file  find /lib/x86_64-linux-gnu | grep '/bin/' |cut -d: -f1|sort -u|wc -l
60

If we make changes to GAP, we need to be able to justify them. So we need a 
real usecase.

This is a real use case, you have not constested until now.

GAP may support multiarch support on multiarch systems: this is clear enough 
for a justification.
Second it does need to be a GAP change, but only a change in the Debian 
distribution.



Cheers,
Jerome

Cheers,
Bill.

--
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