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
signature.asc
Description: Digital signature
