-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello,
On 29/01/14 17:34, Bill Allombert wrote: > 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. Strictly speaking or sticking to the definition, this is correct. 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. But the .o files are architecture dependent, so a multiarch support make sense: as a library is before all a rationalized archive of object, these .o may be gathered into an archive: this will render this part of GAP more contemporary, and this will allow a clean multiarch support. > > 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. I am agree. But the GAP specific setup, /usr/lib/gap/pkg/<GAP Package>/bin/<GAP tuple>/<GAP Package>.so for the <GAP Package> binary module (if any), does not fit well with Debian customs. A possibility will be to ply with links, as it is currently done for documentation, to full fill both Debian policy and GAP expectation. The <GAP tuple> is set up in the /usr/lib/gap/sysinfo.gap : I guess that a good idea would be to replace the <GAP trplet> by the <Debian triplet>. So let assume that the <GAP tuple> is replaced by the <Debian triplet>. Then, wrt the current documentation scheme (for example gapdoc), we can set up the following: /usr/lib/<Debain multiarch triple>/gap/<GAP Package> -> /usr/lib/gap/pkg/<GAP Package>/bin/<GAP/Debian multiarch triple> This favours GAP scheme, the alternative that favours Debain instead can be chosen too: /usr/lib/gap/pkg/<GAP Package>/bin/<GAP/Debian multiarch triple> -> /usr/lib/<Debain multiarch triple>/gap/<GAP Package> > >> 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. Agree. 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. > Can you also ask them to gather the object files into a library ? >> 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. A good idea would be to ask to the upstream team to provide an autotools machinery that is respect better Linux customs: the GAP autotools set ups mainly cast autotools to GAP, it should be the reverse; GAP should provide an autotools machinery that follows Linux custom. This is rather a choice because the effort to do so is not that huge. > 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>/). If the set of objects files is considered as a pre-library, the package must be split: grossly, one containing the headers, the second the library (and the config.h headers). > > Cheers, > Bill. > Best wishes, Jerome -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJS9IMeAAoJEIC/w4IMSybjgGoH/03FIV2M/LErLoVkW29anjBo iuNTUcgaOXUfE45rksvTzto6EVW2g13ExDvsx0td3AFJaO95IkqiUkHFP8yrc5Z1 JozDZ4B/dx+IyWM+zWcu8Motw26x0hGT7ON8QskEetuJ6mL0OUzUCbv5AYBLfEh0 /b7D7tNM3X9S+9gKw0DVH/KDLPa87eu+SEBn4Uch3dWt6K+zlSRkOLnuNZ54Igaz uqwVN+T5q6xNJHwhZx/ny8yT7uefZdg6fYjazh2evfE59+YDr2AwK2qg2CB2y2b+ mZx6zVK2V4H1OxZC6ryXQ5GihNoVZrx8Qg6vQhxMv/ivAccrWdUEcDQFs8rIqLI= =8t3D -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
