[RFC] Adding /local/lib and /usr/lib to default $XDG_DATA_DIRS search path

Lennart Poettering mzkqt at 0pointer.de
Mon Apr 4 09:55:58 PDT 2011

On Mon, 04.04.11 17:43, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> On Mon, 04 Apr 2011 at 18:06:38 +0200, Lennart Poettering wrote:
> > Right now the XDG basedir spec says that $XDG_DATA_DIRS should default
> > to "/usr/local/share/:/usr/share/" if it is not set. I'd like to make
> > one change to this: add "/usr/local/lib" and "/usr/lib" to
> > it. Result: "/usr/local/share:/usr/local/lib:/usr/share:/usr/lib".
> Adding /usr/[local/]lib seems likely to be a problem in multiarch
> environments, since it no longer achieves the division you want:
> * in Debian-style multiarch [1][2], arch-specific files go in
>   /usr/lib/DEB_HOST_MULTIARCH, where DEB_HOST_MULTIARCH is the GNU tuple
>   with the CPU replaced by the most generic in a compatible CPU family
>   (e.g. always something like i386-linux-gnu, x86_64-linux-gnu or
>   arm-linux-gnueabi, and never a newer or more specific compatible variant like
>   i586-linux-gnu or armv7t-linux-gnueabi)
> [1]: http://wiki.debian.org/Multiarch
> [2]: https://wiki.ubuntu.com/MultiarchSpec
> * in Red-Hat-style multilibs, arch-specific files go in /usr/lib or /usr/lib64
>   as appropriate

This is still data files. Not shared libraries. When I wrote /usr/lib I
actually meant /usr/lib as place for non-portable application resources,
I did not refer to any shared library specific multi-arch magic.

> What specific things do you have in mind that would use this feature, and
> could they use one of these alternatives?

Uh, that's a lot of different stuff, like hugepage support for example.

> * search an implementation-defind path before or after XDG_DATA_DIRS
>   (e.g. I think it would be OK for D-Bus or systemd to document that it would
>   look in its compile-time ${libdir} before or after XDG_DATA_DIRS)

Hmm, the XDG basedir spec currently uses the word "should" for the
fallbacks. We could of course say that "should" only means "should" and
systemd is happy.

> * have some flag or metadata in the file like "OnlyOnArch=i386;x86_64;",
>   analogous to the OnlyShowIn=GNOME available in XDG menus

Urks, no. This is also for services where things have different paths
depending on the arch.

> For D-Bus, you asked for /lib/dbus-1/system-services to be in the system
> service search path, for things needed during early boot [3]. Do
> you want that change to happen to XDG_DATA_DIRS too?

No. In my eyes XDG_DATA_DIR is not relevant for system services.

> I think adding /lib (in its role as the root-filesystem equivalent of
> /usr/share) would be less problematic than the change you proposed here,
> if it comes with a note that it always means exactly /lib, and never
> (for instance) /lib32, /lib64 or /lib/i386-linux-gnu.

Yes, /usr/lib means /usr/lib, not /usr/lib64.


Lennart Poettering - Red Hat, Inc.

More information about the xdg mailing list