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?
---------------
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.
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...)
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.
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)
Best,
Adrian
On Sat, Feb 25, 2023, 10:01 Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Sat, Feb 25, 2023 at 9:45 AM Lennart Poettering
<lennart@xxxxxxxxxxxxxx> wrote:
>
> On Di, 21.02.23 16:00, Adrian Vovk (adrianvovk@xxxxxxxxx) wrote:
>
> > Hello all,
> >
> > Would you accept a patch to shared/base-filesystem that makes /usr/lib
> > a fallback link target for /lib64? On my distro I don't support
> > multilib at all and so everything ends up in /usr/lib.
> >
> > So for example, for x86_64 I'd change the target from
> > "usr/lib/"LIB_ARCH_TUPLE"\0" "usr/lib64\0" to
> > "usr/lib/"LIB_ARCH_TUPLE"\0" "usr/lib64\0" "usr/lib\0", and ditto for
> > all the other architectures. That way no matter what, /lib64 always
> > exists when necessary.
>
> I guess that makes some sense on a pure /lib/ file system. Send a
> patch.
>
> (I mean, honestly, I personally wouldn't bother, and just usr /lib64/
> as fedora does and no populate /lib/ with libraries. I mean, it's just
> names, and the ABI is how the ABI is. But regardless, a patch using
> /lib/ as final fallback we search for ld.so in sounds acceptable.)
>
> Submit via github.
>
I don't think that's a good idea. Aside from violating the FHS, it
creates an unexpected problem where multilib or multi-arch *is*
available. If Adrian wants to do that on his own distribution, that's
fine. But as a generic patch in upstream systemd? No way. It would
probably need to be reverted in Fedora and openSUSE (at the minimum)
to prevent chaos.
Adrian, my advice to you: don't do it. Violating the principle of
least surprise is not a good idea.
I would just recommend not having a /usr/lib at all in your system.
--
真実はいつも一つ！/ Always, there's only one truth!
