[systemd-devel] Linking /lib64 to /usr/lib

[Neal Gompa]

On Sat, Feb 25, 2023 at 11:39 AM Adrian Vovk <adrianvovk at gmail.com> wrote:
>
> Well it would only link /lib64 to /usr/lib if both Debian-style and Fedora-style multilib don't exist and the loader is in lib, unless I'm mistaken? I'm pretty sure it should be harmless to Fedora and openSUSE.
>
> Maybe it'd be preferable for me to make a /usr/lib64->/usr/lib link, then let systemd think this is Fedora-style multilib? Would there be any bad side effects from that?
>

That's pretty much how Arch and a few others do it. It should be fine
since you are explicitly not doing multilib in your system.

> ---------------
>
> 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.

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.

> I'm not the only distro doing this. Arch Linux is as well.
>
> I go a little further and actually make binaries I produce look for the loader in /usr/lib as well. This makes the system fully functional just with /usr present (at least that's the goal; still trying to remove references to /bin and friends). I don't actually need /lib64 at all but it should exist for backwards compatibility with existing binaries (as much as I would love to prevent people from running random binaries downloaded from the internet...)
>

This is probably not a good idea.

> Both of these changes are harmless because I'll never support multilib (it's entirely unnecessary for the software I distribute) and nobody should expect to be able to run a binary from distro A on distro B anyway.
>

"nobody should" != "nobody would".

> Anyway that's beside the point. I've been set up like this for a while now. Perhaps one day I'll switch back to a more proper layout, but that would be a change that will probably break things across the distro (again, due to the whole "what goes into lib vs lib64" confusion)
>

Well, it should be easy enough for you to just shift existing binaries
and tweak your build stuff so things go into lib64 going forward.




-- 
真実はいつも一つ！/ Always, there's only one truth!