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

[Duncan]

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman