Re: Linking /lib64 to /usr/lib

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sa, 25.02.23 13:41, Neal Gompa (ngompa13@xxxxxxxxx) wrote:

> > Maybe I should explain my reasoning:
> >
> > Part of the reason I didn't do the split is to be less surprising. My distro has no package management, nor does it have multilib. The /usr/lib64 vs /usr/lib split has always been surprising to me as a user of Fedora, and I'm never quite sure if I'll find something in lib or in lib64 (lib/systemd or lib64/systemd or both? lib/pkgconfig or lib64/pkgconfig or both? lib/locale or lib64/locale? You get the idea). Because I have no multilib, this split becomes unnecessary. Thus, I can resolve all the ambiguities above in favor of lib, which makes life easier and (imo) less surprising.
> >
>
> This is less ambiguous than you'd think. Outside of systemd putting
> executables in /usr/lib/systemd (rather than /usr/libexec/systemd),
> pretty much everything goes into the /usr/lib64 hierarchy for x86_64
> stuff.

libexec is a redhatism. A useless one at that... I am not aware of any
reason for splitting this up besides feelings.

On fedora /usr/lib64/ is the place for 64bit-specific shared
libraries. All other non-shared resources should be in /usr/lib/<package>.

> In ancient times, systemd needed to pick directories that existed in
> FHS on / and /usr, which led to unit files and executables being
> installed in /lib. There is no /share or /libexec directories, and no
> one (back then) was interested in adding them. Today, systemd
> basically expects /usr hierarchy, which has /usr/share and
> /usr/libexec. I don't know if this will ever get fixed (probably not),
> but it's basically an accident of history.

Nah. You got that all wrong. This is not why systemd is doing what it
does. systemd's logic is like this:

per-arch libraries we put in debian-style /usr/lib/<triplet>/ or the
less generic fedora-style /usr/lib64/ vs. /usr/lib/ dirs. This is the
stuff that must exist in multiple versions if you want to support
multlib. /usr/lib/<package> we use for our own stuff, which we
inherently own, and is our kingdom. /usr/share/ is for stuff with
shared ownership (i.e other packages own as much as we do), that must
also be arch-independent.

This was always that way, and still is. It's also what we documented
in file-hiearchy(7).

And no we are not going to "fix" anything in this area, because
there's nothing broken.

Lennart

--
Lennart Poettering, Berlin



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux