Re: Debian policy update (3.8.4.0)
Simon McVittie <smcv@debian.org> writes:
> 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.
You can move headers, the *.so link and static libs. But .pc and .la
files can not be in the triplet dir yet afaik. So that is a no go for
now. But if you want you can try and see what changes libtool and
pkgconfig would need for this.
>> > 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).
Maybe that is documented in gcc somewhere.
> 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?
I believe so. /usr/include/triplet is at least preferable to
/usr/lib/triplet/package/include as the former is in the default include
path and works without -I option.
> 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?
I would rather assume the opposite, that headers are arch independent
and dpkg will then makes sure of that during install at the latest. So
while the assumption might be wrong it is not dangerous.
> (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.)
Most of /usr/lib/glib-2.0/include/glibconfig.h is already arch
independent or can trivialy be rewritten as such using C99. Imho that
would be preferable. But short of that those have to go into a triplet
dir eventually. The common theme here seems to be that it is *config.h
as generated by configure. Maybe some automatism can be added to
autoconf/automake to automatically put such files into
/usr/include/triplet.
As said, developement packages still need work to figure out the best
practices and adjust the toolchain. So for now keep them as is.
> Regards,
> Simon
MfG
Goswin
Reply to: