Re: Debian policy update (3.8.4.0)
Simon McVittie <smcv@debian.org> writes:
> (Please cc me on this thread, I'm not subscribed to debian-devel.)
>
> 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.
> 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? If
your library uses any plugins then you need to compile it for
/usr/lib/${DEB_HOST_GNU_TYPE} and not just move the files there post
build.
> libdbus is probably an interesting example if you want to do that because it
> has one architecture-dependent header file, which it places in ${libdir}, and
> keeps the rest of /usr/include architecture-independent.
Architecture dependent header files belong under
/usr/include/triplet/
That directory is searched by default in gcc so it works without extra
-I option. Preferable to ${libdir}. But dbus screws that up as well as
it uses a subdir for its files.
> .pc file:
>> prefix=/usr
>> exec_prefix=${prefix}
>> libdir=${exec_prefix}/lib
>> includedir=${prefix}/include
>> system_bus_default_address=unix:path=/var/run/dbus/system_bus_socket
>> sysconfdir=/etc
>> session_bus_services_dir=/usr/share/dbus-1/services
>> daemondir=/usr/bin
>>
>> Name: dbus
>> Description: Free desktop message bus
>> Version: 1.2.16
>> Libs: -L${libdir} -ldbus-1 -lpthread -lrt
>> Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include
Cflags: -I${includedir}/dbus-1.0 -I${includedir}/i486-linux-gnu/dbus-1.0
Would be better but your solution is policy conform too I think.
> I'd also be happy to multiarchify libgfshare (a small library using autotools
> and debhelper 7) if that would make a useful example of how to do the simple
> case; it's in collab-maint bzr, and you're welcome to commit there if that
> would help. I'd also be happy to migrate it to collab-maint git (which
> I've considered doing anyway) if that's easier for you to deal with.
>
> Regards,
> Simon
MfG
Goswin
Reply to: