On 04/06/2016 01:34 AM, Duncan wrote:
> Richard Yao posted on Wed, 06 Apr 2016 00:15:58 -0400 as excerpted:
>
>
>>> On Apr 4, 2016, at 9:19 PM, William Hubbs <willi...@gentoo.org> wrote:
>>>
>>> All,
>>>
>>> I thought that since the usr merge is coming up again, and since I lost
>>> track of the message where it was brought up, I would open a new thread
>>> to discuss it.
>>>
>>> When it came up before, some were saying that the /usr merge violates
>>> the fhs. I don't remember the specifics of what the claim was at the
>>> time, (I'm sure someone will point it out if it is still a concern).
>>
>> Here are the violations:
>>
>> http://refspecs.linuxfoundation.org/FHS_3.0/
> fhs-3.0.html#binEssentialUserCommandBinaries
>>
>> http://refspecs.linuxfoundation.org/FHS_3.0/
> fhs-3.0.html#sbinSystemBinaries
>>
>> http://refspecs.linuxfoundation.org/FHS_3.0/
> fhs-3.0.html#libEssentialSharedLibrariesAndKern
>
> (Those links are wrapped and I'm not bothering to jump thru the hoops to
> unwrap them, since readers can either unwrap them manually or refer to
> the parent post I'm quoting for the unwrapped versions.)
>
> If those are the "violations", then putting everything in /usr and making
> the /bin and /sbin locations symlinks isn't going to be a problem, since
> /bin and /sbin are specifically allowed to contain symlinks to the
> executables, instead of the executables themselves, and if the dirs
> themselves are symlinks to the locations in /usr with the files, that
> fulfills that requirement.
Alexis Ballier pointed out that the following had been added to make
this okay:
> The following directories, or symbolic links to directories, are
required in /.
As far as the Single UNIX Specification is concerned, this sort of thing
is okay. The Linux Filesystem Hierarchy Standard that further restricts
things had not been updated to permit this until mid-2015.
> And the requirement for /lib is rather vague, saying only that it
> contains the libs linked by the executables in /bin and /sbin. So once /
> bin and /sbin are symlinks to the dirs with the executables, /lib (or the
> arch-specific alternative libdirs) can be a symlink as well.
>
> Tho I must say doing the reverse, making either /usr itself or /usr/bin
> and /usr/sbin symlinks to the root dirs, as I did here, actually makes
> more sense and bends the rules less.
I agree, but Solaris picked the other way and RHEL followed. My opinion
is that we should support both. Any automated upgrade scripts that do
the /usr merge on behalf of users should detect this state and leave it
alone.
That being said, I am not of the opinion that we should migrate existing
installs or drop support for the older layout for a couple reasons. One
is that existing installs will see no benefit from this layout change.
The other is that supporting the existing installs is necessary so that
we can still do QA on them.
I suspect breakage will be more likely with the older layout than the
newer one. If we end up not migrating existing installs automatically
(maybe via a profile change), we might be able to get away with doing
the majority of testing with the older one. If we do not want to do that
long term, we could always do it for something like a year to minimize
the effect on the userbase.
A portage QA check could be made to detect the presence of files in both
/{bin,sbin,lib,lib64,lib32} and /usr/{bin,sbin,lib,lib64,lib32} to make
verifying that packaging does not do anything weird that would
negatively affect the newer layout easier when testing with the older
layout.
The only exception being the linker scripts. There are at least a few of
them still around:
richard@desktop ~ $ for fA in /lib/*; do
> fB=/usr/lib/${fA##*/};
> [[ -f $fA && -f $fB ]] && echo "$fB";
> done
/usr/lib/libeinfo.so
/usr/lib/libpamc.so
/usr/lib/libpam_misc.so
/usr/lib/libpam.so
/usr/lib/librc.so
richard@desktop ~ $ cat /usr/lib/librc.so
/* GNU ld script
Since Gentoo has critical dynamic libraries in /lib, and the static
versions
in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib,
otherwise we
run into linking problems. This "fake" dynamic lib is a linker
script that
redirects the linker to the real lib. And yes, this works in the cross-
compiling scenario as the sysroot-ed linker will prepend the real path.
See bug https://bugs.gentoo.org/4411 for more info.
*/
OUTPUT_FORMAT ( elf64-x86-64 )
GROUP ( /lib64/librc.so )
I am a bit out of date on the status of these. Do we still need them? If
we have not already, we could patch GNU ld to eliminate the need for this.
> Basically, what the FHS says, at least in the 3.0 version you linked, is
> that the executables must be reachable via whatever specific path, but
> using symlinks to do it is fine.
>
> Which means the merge is allowed, as long as symlinks allow the
> executables to be reached by their specifically defined paths. And I'm
> not aware of anyone seriously proposing that said symlinks be omitted,
> so...
My mistake. I had not spotted that change in my cursory read. At least
we now know that this is not a Linux FHS violation anymore. :)
