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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org