On Wed, 08 Aug 2012 11:09:15 +0200, Remi Collet wrote:
> > It's a bug in the same way it would be a bug if the headers were stored
> > below %_bindir, %_mandir, %_sysconfdir or dirs other than %_includedir.
>
> I mostly agree, but...
> Where arch specific header should go ?
%{_includedir}/something-target-cpu-dependent/
and have $(pkg-config --cflags) return that directory. With a versioned
topdir, one example would be:
/usr/include/libname-1.0/${ARCH}/libname/*.h
$ pkg-config --cflags libname-1.0
-I/usr/include/libname-1.0/${ARCH}
#include <libname/….h>
It could even be the upstream installer doing that, with arch-dependent
conditionals in platform-independent headers including the arch-specific
bits from subdirs.
/usr/include/libname/*.h
-> /usr/include/libname/${ARCH1}/*.h
-> /usr/include/libname/${ARCH2}/*.h
And if it weren't a versioned topdir, you could even access the header
files without extending search path list, since /usr/include is a default
search path whereas %_libdir is not.
> $ find /usr/lib64 -name \*.h | wc -l
> 393
>
> most are perl and qt headers,
> but some gnome package also put their header here.
Qt also stores (or used to store) executables somewhere below %_libdir,
using it as some sort of home/root dir. Not a suitable counter-example
to prove anything other than that some more headers are misplaced.
> Currently we use some workaround (see mysql or libzip)
> /usr/include/mysql/my_config.h
> /usr/include/zipconf.h
>
> (libzip upstream also use %{_libdir} for zipconf.h)
>
> So, I think, %{_libdir}/foo/include is not a so bad solution.
For multiarch, it's a work-around only, a lazy one, as %_libdir is a quick
way to get a directory that differs by arch.
--
Fedora release 17 (Beefy Miracle) - Linux 3.5.0-2.fc17.x86_64
loadavg: 0.00 0.09 0.39
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
