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

Bill Allombert Bill.Allombert at math.u-bordeaux.fr
Sun Nov 6 14:20:34 GMT 2022


On Sun, Nov 06, 2022 at 02:18:52PM +0100, Jerome BENOIT wrote:
> 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.

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.

> > > > > > > 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)/
> > > > I guess that a patch can be written to do so.
> > 
> > This probably requires changing the C code to define a new GAPInfo.DEB_HOST_MULTIARCH field.
> > Do you have a better idea ?
> 
> I am ready to write such a C patch. Is that okay with you ?

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



More information about the debian-science-maintainers mailing list