On Sat, Jun 07, 2025 at 01:12:14AM +0200, Jerome BENOIT wrote: > 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.
But it seems to me the normal place for such binary should be /usr/bin with a prefix, as it is done with gap-nq, or alternatively in /usr/libexec/gap without a triplet. Why do you need to deviate from that ? Cheers, Bill.
