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

[Bill Allombert]

On Wed, Nov 02, 2022 at 11:13:07AM +0100, Jerome BENOIT wrote:
> Hello Bill, thanks for your message.

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.

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

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

> 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 ?

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.

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

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,
-- 
Bill. <ballombe at debian.org>

Imagine a large red swirl here.