Re: Debian policy update (3.8.4.0)
On Mon, 01 Feb 2010 at 20:46:18 +0100, Goswin von Brederlow wrote:
> > Goswin wrote:
> >> Looks fine from here. How does your -dev package look? The .so link, .la
> >> and .pc files (if any) are specifically important.
> >
> > The -dev package has no Multi-Arch field, which seems to be how the multiarch
> > spec on the Ubuntu wiki intends things to be done? As such, I'm still using
> > /usr/lib for the -dev part.
>
> Initialy yes. But esspecially for cross compiles multiarch dev packages
> would be nice. But that will need more developement.
In the meantime, is there consensus that shuffling the development files into
/usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
appropriate for -dev packages where all the arch-dependent files are in
arch-specific directories? I'd rather not break future work if -dev packages
aren't really settled yet.
> > It'd be somewhat more complex to rearrange things for a multiarch -dev package,
> > but could be done; I assume the recommended way to do that would be to use
> > "./configure --libdir=/usr/lib/${DEB_HOST_GNU_TYPE}"?
>
> How do you get the libs into /usr/lib/${DEB_HOST_GNU_TYPE} currently?
Currently, with dh_install - libdbus happens to not hard-code paths, and thus
work correctly when it's just moved around (Michael already moved it from
/usr/lib to /lib for Upstart's benefit, so this definitely does work). I
realise this doesn't generalize to all libraries, in particular those that
hard-code paths (generally to load plugins, like you said).
> Architecture dependent header files belong under
>
> /usr/include/triplet/
Is there consensus that that's the right place? I don't see any mention on
<https://wiki.ubuntu.com/MultiarchSpec>, which is the nearest I've seen to
a canonical description of the current state of multiarch (no pun intended).
For packages like libdbus that already split out arch-dep headers to ${libdir}
there doesn't seem any point in trying to override that, but for packages
that don't necessarily make sure their headers are arch-indep, would it be
appropriate to use --includedir=/usr/include/triplet, i.e. pessimistically
assume that every header is arch-specific?
In particular, generic tools that run configure automatically, like
dh_auto_configure and cdbs, would probably have to assume that every package
contains arch-specific headers unless told otherwise; am I right?
(Some concrete examples: GLib and GDK also have one arch-specific header in
${libdir} each; expat is one of several with a version of config.h in
/usr/include; Python has pyconfig.h in a /usr/include subdirectory.)
Regards,
Simon
Reply to: