On Tue, 02 Feb 2010 at 14:22:49 +0100, Goswin von Brederlow wrote:
> 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.
Removing .la files (in the right order, leaf packages first) is a release goal
anyway, so I think it would be reasonable to say that only -dev packages that
have already lost their .la files (like dbus) can be multiarch.
`pkg-config --debug 2>&1 | grep i486` (on my i386) reveals that pkg-config
already looks in /usr/lib/pkgconfig/i486-linux-gnu; perhaps it could be made
to search /usr/lib/TRIPLET/pkgconfig too (hackish version:
/usr/lib/pkgconfig/TRIPLET could be a symlink there, on Debian).
However, this would also require that pkg-config itself was multiarch or
otherwise supported cross-compilation (/usr/bin/i486-linux-gnu-pkg-config,
like AC_CHECK_TOOL would use? pkg-config --arch=i486-linux-gnu? etc.); until
then, it's not useful for pkg-config-using libraries to be multiarch (if
I have i386 and amd64 versions of libdbus-1-dev, but only the one whose
architecture matches my version of pkg-config actually works, then I might
as well uninstall the other version of libdbus-1-dev).
I'd be interested to hear from Tollef what the plan is regarding pkg-config
and multiarch.
In the meantime, from the point of view of the multiarch cabal, which of these
is most correct?
* pkg-config'd libraries should not be multiarch until pkg-config supports it,
but the .a, .so should go in /usr/lib/TRIPLET as soon as possible
* pkg-config'd libraries should not be multiarch until pkg-config supports it,
and until then they should ensure that the .a, .so stay in /usr/lib
* pkg-config'd libraries may do whichever of those is most straightforward
> /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.
That defeats the purpose of using the dbus-1.0 subdirectory, which is precisely
to *not* be on the default inclusion path, for parallel-installability across
some future API break, perhaps to dbus-1.5 or dbus-2.0 or something (D-Bus
hasn't needed to do this, but the migration from Gtk 1.2 to 2.0 did, and
Qt 3 -> 4 appears to do the same).
Whether you personally consider this design broken or not, it exists and is
widespread, and multiarch should cope; the major advantage is that it avoids
the need for the mutual Conflicts seen in e.g. libdb4.x-dev.
In cases where an API-specific subdirectory is used by upstream for that
purpose, sticking to upstream's choice of
/usr/lib/TRIPLET/PACKAGE-API/include vs. /usr/include/TRIPLET/PACKAGE-API
is considerably easier than not, and I don't really see a technical argument
one way or the other when the default -I path is no longer relevant; is
there one that I'm missing?
> > (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.
GLib upstream supports pre-C99 compilers, so that's unlikely to be feasible
(unless you want Debian to fork GLib, which seems like a recipe for disaster).
Regards,
Simon
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
