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