[systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Simon McVittie]

On 08/04/15 20:11, Kay Sievers wrote:
> Right, we have to find out what we want to support here, cross-compile
> or secondary arch things.
> 
> Only one thing is clear at the moment, that the current status makes
> no sense. :)
> 
> We got $libdir for the secondary arch:
>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=eb39a6239c631873db62f6a942e6cb3dab0a2db4
> 
> But then we took $libdir as the reason to move the file and make it
> inaccessible for the secondary arch:
>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=aec432c6134146e138124c4130be2ee89dca07fa

I think the question to be asking is, what API does systemd.pc
represent? Is it the architecture-independent "drop unit files in these
directories..."-style API of the systemd init system and related things,
or is it a C ABI?

If it's the various architecture-independent APIs (unit files, D-Bus,
etc.) then $datadir/pkgconfig is an appropriate place. If it's a C API
then $libdir/pkgconfig would be appropriate, but AIUI the C API is
libsystemd, which already has its own separate .pc file.

I don't think systemd.pc is really the appropriate place to answer the
question "what is the preferred library directory for the primary
architecture on this system?", because there doesn't seem to be anything
about systemd that makes its CPU architecture particularly important.
Yes, systemd is in a unique position because it's pid 1, so there can
only be one of it; but it doesn't actually seem to *do* anything with
the $libdir? For the normal libraries to which it is linked (libselinux
or whatever), it relies on ld.so's configured search path rather than
doing its own thing; it doesn't load plugins, which is one situation
where applications might need to know the preferred $libdir themselves;
and it deliberately always uses /[usr/]lib, never
/[usr/]lib/i386-linux-gnu or /[usr/]lib64, for architecture-independent
APIs like units and tmpfiles snippets.

If I wanted to find "the primary architecture" on a particular system,
I'd start by looking at the toolchain (in particular, what /usr/bin/cc
produces and where it looks for libraries), the kernel, and/or the
package manager (Debian-style multiarch doesn't necessarily need to have
a primary architecture at all, but the de facto standard for finding the
closest-to-primary architecture where needed is to look in "dpkg -s
dpkg" and see which architecture it is).

Similarly, when compiling software, I don't think it's the upstream
developer's place to be redefining $libdir (or indeed $prefix) according
to local practices. GNU-style software defaults to /usr/local/lib, which
is not the most appropriate location for *any* packaging system (except
possibly *BSD "ports") - but all distributions already know that, and
have a standard set of configure arguments to redirect --prefix and
--libdir to their preferred paths, whether that means
/usr/i686-linux-gnu/lib or /usr/lib/i386-linux-gnu or /usr/lib64. It
seems better for third-party software to be predictable about its
installation paths, rather than for it to "do what I mean" and alter its
defaults depending whether it thinks it's on a Debian or Red Hat derivative.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>