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 -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
