Re: [gentoo-dev] Re: rfc: multilib and fhs 3

[William Hubbs]

On Sun, Oct 11, 2015 at 09:46:20AM +0000, Duncan wrote:
> William Hubbs posted on Sat, 10 Oct 2015 17:48:15 -0500 as excerpted:
>
> > All,
> >
> > fhs 3.0 was approved in June this year [1] [2].
> >
> > The piece of it that I want to bring up is the lib and libxx
> > directories, both in / and /usr. The way I read the fhs, /lib and
> > /usr/lib should hold the files for the default abi and /libxx and
> > /usr/libxx should hold the files for the alternate abis. In earlier fhs,
> > there was an exception for amd64 which stated that the default libraries
> > should be in /lib64 and /usr/lib64. However, that exception is now gone.
> >
> > I know there was discussion/work in the past on removing the lib->lib64
> > symlinks on amd64, but I don't remember what happened to that
> > discussion. So, I would like to bring it up again and get the info.
> >
> > What would it take for us to remove the lib->lib64 links?
> >
> > What would it take for us to do this migration on live systems?
> >
> > William
> >
> > [1] https://wiki.linuxfoundation.org/en/FHS [2]
> > http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
>
> I don't know what the current status is, but years ago, I used to run
> portage with FEATURES=multilib-strict.  There weren't many violations in
> my installed base at the time, and when there were I filed bugs.
>
> This biggest problems didn't have to do with installing to the wrong
> place, but rather, with configuration paths, etc, not being corrected,
> resulting in runtime errors if lib and lib64 were not in fact the same
> directory, via symlink or whatever.  IIRC, openrc itself, or at least
> some openrc initscripts, possibly owned by other packages, was quite a
> headache in that regard.
>
> However, I killed multilib-strict some years ago when I went no-multilib,
> and after experiencing problems when lib and lib64 weren't in fact the
> same dir, I've not touched those symlinks in years, plus I run systemd
> now so wouldn't know about openrc's status even if I was aware of the
> general status, so I've no idea what the current status is.
>
> But multilib-strict in fact checks that packages use lib64 for 64-bit elf
> libs (tho I think it might actually get the specifics from the profile,
> the amd64 or portage folks should be able to say for sure), failing the
> install if lib is used instead, so if in fact FHS 3.0 reverses that, we'd
> either have to reverse its check, or possibly configure a test to some
> third directory, and then do a test run to catch anything that's
> installing to either location, hard-coded.
>
> Tho as I said, the actual installed installation isn't the entire
> problem.  Multilib-strict doesn't catch it when a binary is installed to
> the right place, but some configuration hard-coding isn't corrected and
> still points elsewhere, so if the two locations aren't symlinked or
> otherwise actually the same location, things break.  That's somewhat
> harder to find, and in my experience, the worse headache to try to deal
> with, since it's often only caught at runtime, and even then, may only be
> caught in specific corner-cases when something doesn't load or isn't
> found that you know is installed and should be found and load.

If I'm reading the new fhs correctly, /usr/lib64 and /lib64 should no
longer exist and we should put all 64 bit code in /usr/lib and /lib.
This means all no-multilib and multilib setups would have
/usr/lib and /lib directories, and multilib setups would add /usr/lib32
and /lib32. It is not a reversal; it is the equivalent of
"rm lib;mv lib64 lib" run both in / and /usr.

William