Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7
Jerome BENOIT
calculus at rezozer.net
Mon Jun 9 12:56:21 BST 2025
On Mon, 9 Jun 2025 12:14:47 +0200 Bill Allombert <Bill.Allombert at math.u-bordeaux.fr> wrote:
Hello Bill, thanks for your reply.
> 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.
(For completeness, the Debian gap-nq package was sponsored by you.)
>
> Why do you need to deviate from that ?
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.
Why do you need to deviate from the Debian policy ?
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/5bb0ddf0/attachment.sig>
More information about the debian-science-maintainers
mailing list