On Thu, Jan 23, 2014 at 09:46:45AM +0100, Jerome Benoit wrote: > Package: gap-dev > Version: 4r6p5-3.1 > Severity: wishlist > > Dear Maintainer, > > please provide multiarch support for gap-dev: > the distributed object files in /usr/lib/gap/bin/ > should be placed into an architecture dependent subfolder as > /usr/lib/gap/bin/<multiarch name>/ , while the GAP environment > variable GAPInfo.Architecture should be set up arccordingly > (for this example, to <multiarch name>). > This will bring multiarch support to GAP
Hello Jérome, Multiarch is only intended to cover shared library. There is currently no support in Debian for multiarch executables. GAP does not provide any shared libraries, but an executable, so is outside the scope of multiarch, and I do not think it is worth the effort to have multiarch support for GAP at this stage. The .o files are only meant to be used by the GAC compiler. If we move toward using multiarch path (irrespectively of actual multiarch support), then we should use /usr/lib/<multiarch triplet>/gap and not a GAP specific path. > and it will also > satisfy some GAP expectation as expressed in the ac_find_gap.m4 > used by some GAP packages with binary modules. I do not intent to support such expectation. The value of GAParch is something like x86_64-pc-linux-gnu-x86_64-linux-gnu-gcc-default64 and change each time the compiler name change. This is too fragile to be used by Debian. I am working with upstream to improve this (in particular: not include the compiler name in the ABI). In the mean time, my plan is to use /usr/share/gap/pkg/<name>/bin instead. This can be a symlink to /usr/lib/<multiarch triplet>/gap/pkg/<name/bin. > Note that the configure header /usr/include/gap/config.h > (current Debian package location) > is architecture dependent as well: > ac_find_gap.m4 expects to find it in > /usr/lib/gap/bin/<GAPInfo.Architecture>/. Yes, I know. There is a trade-off between keeping file where upstream expect them and put them where Debian expect them. Upstream do not provide a 'make install' target as a guidance. If the current location prove to be too much an issue, I am willing to reconsider it, or add work-arounds. > (I guess that the current gap-dev package > must be split.) The multiarch specification for header files are not fully specified yet, but I do not think splitting the package is necessary (However some headers would need to be moved to /usr/include/<multiarch triplet>/). Cheers, Bill. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
