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=calculus@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 1533 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20250609/2bb55705/attachment.sig>