Re: Patch for MultiarchCross
Steve Langasek <vorlon@debian.org> writes:
> Hi there,
>
> On Wed, Mar 23, 2011 at 03:05:53AM +0000, Wookey wrote:
>
>> The Multiarch specification only covers libraries and does not
>> specifically deal with include files.
>
>> To make multiarch useful for cross-building as well as co-installation of
>> libraries we need to install headers to /usr/include/<triplet>, which
>> needs an FHS exception.
Maybe we should stop calling it <triplet> since it isn't the gnu triplet
anymore (at least for some cases)?
>> Here is a patch to policy to allow that. It could repeat most of the
>> libraries section above but there seemed little point. I'm happy to
>> expand it though if we think that would be helpful.
>
>> I'm not sure if anything else in policy needs to be adjusted - I
>> didn't see anything obvious.
>
> The only thing I wonder is whether we should go farther yet and make this a
> policy recommendation rather than just granting permission... but since
> we're only just now implementing toolchain support for this, I guess that
> might be premature.
I would make this a recommendation but only for include files that
differ between architectures and for any package that uses multiarch
paths. Those packages already need the Pre-Depends on the multiarch
package. The multiarch package must then ensure not only that the ld.so
works with multiarch paths but also that a suitable toolchain is
used (Break on unsuitable toolchain packages, not depends).
What we don't want is every library package deciding on their own
solution on where to put files and many long -I ... options or gcc not
finding the files.
What could be allowed is using the new include paths with a Depends on
the multiarch package even if the package itself is not multiarch.
>> I would file this as a bug against debian-policy but I don't know
>> whether it should be normative, informative, etc. Advice welcome.
>
> Reading the FHS carefully, I see that there is no requirement for headers to
> be installed *directly* under /usr/include, only that they be installed
> *somewhere* under this directory. And indeed, many packages create
> subdirectories under /usr/include already. So maybe it's not actually
> needed to override the FHS at all for /usr/include, until the time that
> we want to make this a policy recommendation?
>
> I.e., I guess this isn't a "normative" bug because we're not actually
> changing any rules; and it's not really "informative" either because we're
> not actually providing much information yet. :) Do you think there is a
> specific recommendation policy should make right now, or should we defer
> amending policy until the prelim implementation is farther along in
> unstable?
MfG
Goswin
Reply to: