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

[Jerome BENOIT]

Hello Bill,

On 06/06/2025 21:00, Bill Allombert wrote:
> On Tue, Jun 03, 2025 at 11:11:07PM +0200, Jerome BENOIT wrote:
>> Hi, finally I found some time to write a working patch.
>>
>>
>>>> I am ready to write such a C patch. Is that okay with you ?
>>>
>>> Depends on messy it is, I guess ? The problem is that once packages
>>> start to use that patch, I cannot just drop
>>> the patch if it fails to apply to a new upstream version.
>>>
>>
>> I try to make it not Debian specific (ie, it is applicable to upstream version in its main part),
>> minimal, and clean (not messy).
>>
>> Note the the patch apply to the Debian source gap-4.140-3, namely the one currently in Sid.
>> Second, after applying the patch, the `configure' and `src/config.h.in' files must be regenerated.
>> This can be done by launching `autogen.sh'.
> 
> Hello Jerome, could you describe the use case ? This is unclear to me.

The GAP package guava gives us a use case.

The GAP package guava installs a couple of binary executables.
As such these executables are architecture dependent, so they can not be put in /usr/share/gap/pkg/guava/bin/ ,
which is architecture independent. However they are not built upon the gap kernel so we can not put
these executables in /usr/share/gap/pkg/guava/bin/<<GAPInfo.Architecture>> either because the "GAP multi arch tuple"
(that is `GAPInfo.Architecture`) reflects a GAP specific hierarchy that is different from the Debian multi-arch hierarchy.
In fact, these executables must be installed with respect to the Debian multi-arch hierarchy scheme and they must be
reachable from within GAP since these executables are called by GAP procedures. The solution suggested by this patch
is to set up  a /usr/share/gap/pkg/guava/bin/<<Debian triplet>> where those kind of executables can find a place.
This suggestion respects both the GAP scheme and the Debian scheme. Note also that the way that the patch implements
and uses GAPInfo.HostMultiArchTuple (namely DEB_HOST_MULTIARCH for Debian systems) follows the way that GAP implements
and uses GAPInfo.Architecture.

Best wishes,
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/20250607/92035325/attachment-0001.sig>