On Mon, 9 Jun 2025 12:14:47 +0200 Bill Allombert <bill.allomb...@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=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
OpenPGP_signature.asc
Description: OpenPGP digital signature
