Package: gap-guava-bin
Version: 3.17+ds-2
Severity: normal

Dear Debian Science Maintainers,

gap-guava-bin includes the directory
/usr/lib/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv7
but does not depend on gap-kernel-7.

1) As far as I can see, the guava binaries are not linked against the gap-kernel
so are independent of it, so the binaries should just go to
/usr/lib/gap/pkg/guava/bin/

2) the new gap kernel 4.12 is gap-kernel-8 and will not find binaries in
x86_64-pc-linux-gnu-default64-kv7

3) if for some reason, you really need x86_64-pc-linux-gnu-default64-kvN, you
need to depend on gap-kernel-N.

Cheers,

Hello Bill, thanks for your message.

I was trying to fix the issue when you sent the report.
I isolated the issue as you did.

Solution 1) would the solution on box with one architecture, not on box with multi-architectures.
The package test relies DirectoriesPackagePrograms gap procedure (see debian/tests/makecheck.tst )

In Sid environment as provided by autopkgtest(1),

DirectoriesPackagePrograms( "guava" )

gives

[ dir("/usr/share/gap/pkg/guava/bin/"), dir("/usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/") ]

which is in agreement with your comments.

However only the last dir[ectory] may work on muti-architecture boxes.
Here we would need a "/usr/share/gap/pkg/guava/bin/<arch-triplet> between the two current ones:
can gap support this ?


Meanwhile (before reading your report) I gave a new try by imposing gap >= 4.12 .


Best wishes,
Jerome

Hello Jerome,

Please keep in mind that the BTS does not forward email to the submitter so
you always need to CC them otherwise they will not see your answer!
I only found it by luck, because I see your upload.

Indeed, the GAP patch debian/patches/program-path adds
/usr/share/gap/pkg/guava/bin/ to this list.

GAP does not have the notion of the Debian triplet, so it is difficult to write a patch
to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/

There is a single /usr/bin for all archs, so in particular a single /usr/bin/gap,
so I do not see why we need to support several /usr/share/gap/pkg/guava/bin,
especially since mismatched gap-core and gap-guava-bin should work.

This is not sufficient, because it will break again when kv9 happens, for no reason.
Without this bug, gap would be in testing today.
My only way out is to reupload gap with Breaks: gap-guava-bin (<= 3.17+ds-2),
which will waste 5 days.

Also this is an artificial dependency ( guava only requires >= 4.8.0) that will make
upgrades more complex, again for no reason.

Cheers,

Hello Bill, thanks for your reply.

I guess that a patch can be written to do so.

Along this reasonning, /usr/share/gap/pkg/guava/bin/x86_64-pc-linux-gnu-default64-kv8/ has no use.

I agree.

This is migration in action.

The only way out is to fix [gap-]guava .

Indeed.


Please let me fix this guava issue by the week-end.

Best wishes,
Jerome

This probably requires changing the C code to define a new GAPInfo.DEB_HOST_MULTIARCH field.
Do you have a better idea ?

Indeed. gap only need to support it for compatibility with non-debian-packaged gap packages,
that uses this kind of directory name.

OK, thanks!
Bill.

Hello Bill, I got a closer look.

It appears that [gap-]guava auxiliary binaries do not depend on gap-dev related packages.
We must discard this dependency a part of resolving the issue.
However, these auxiliary binaries are C compiled executables, that is to say
that they are not scripts.
Therefore the comment above/below is relevant.

I am ready to write such a C patch. Is that okay with you ?

Best wishes,
Jerome

Yes, and as I said the program output is the same on all architectures,
so it does not need to match the gap architecture, so there is no reason to
handle it specially. In particular there is no use to install two version of the
program for two different architectures.

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.

Cheers,
Bill

Hi, finally I found some time to write a working patch.

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'.

Please let me know if the patch is fine, and, if not, what can be improved.

Cheers,
Jerome

Hello Jerome, could you describe the use case ? This is unclear to me.

Cheers,
Bill.

Hello Bill,

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

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.

On Mon, 9 Jun 2025 12:14:47 +0200 Bill Allombert <Bill.Allombert@math.u-bordeaux.fr> wrote:

Hello Bill, thanks for your reply.

(For completeness, the Debian gap-nq package was sponsored by you.)
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

There is no such expectation. If you run x86-sh on a amd64-coreutils system,
'ls' will run the amd64 binary, not the 32-bit binary.

Where does policy mandates /usr/libexec/<triplet> ?

$apt-file -l search /usr/libexec/x86_64-linux-gnu|wc
      9       9     106
$seventeen - ~#apt-file -l search /usr/libexec|wc
    465     465    6538

So overwhelmingly, /usr/libexec/<triplet> is not used.

Cheers,

On 09/06/2025 14:55, Bill Allombert wrote:

Hello,

I would not compare the stability of ls(1) with the stability of the executables provided by gap-guava.
Having said that, as a scientist, I would expect the behavior that I described.

My argument is based on the executable-in-usr-lib lintian tag [1]:

==================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> .

The former is widely used:

# apt-file  find /lib/x86_64-linux-gnu | grep '/bin/' | wc -l

gives on Sid

2576

Furthermore the final `bin' may not be present, so this number must be larger.


I acknowledge that  /usr/libexec/<archtriplet> is not often mention in the main policy document.
So far I can remember, this tag is relatively recent. And since its severity is pedantic,
package maintainers may not bother to make the move. Whatever, this does not affect the present issue.
This might explain that.

In final I think that this tag needs to be clarified.
I am considering the submit a bugreport.
Meanwhile I am also considering to write wrapper instead.

Cheers,
Jerome

[1]

No they should be moved to /usr/libexec/<package>.
Neither the FHS nor Debian policy define /usr/libexec/<triplet>.
When multiarch was designed, it was decided multiarch would only cover
/lib and not /bin.

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/.

You are counting packages multiple time. Consider

% 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.

Cheers,
Bill.

Hi,

This would be a regression.

They do not forbid it either.

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.

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.

I am counting binaries one time.

Second, counting does not make a rational.
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