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
