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

Adrian Vovk adrianvovk at gmail.com
Sat Feb 25 16:39:05 UTC 2023


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 at gmail.com> wrote:

> On Sat, Feb 25, 2023 at 9:45 AM Lennart Poettering
> <lennart at poettering.net> wrote:
> >
> > On Di, 21.02.23 16:00, Adrian Vovk (adrianvovk at gmail.com) 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230225/1b4e285a/attachment.htm>


More information about the systemd-devel mailing list