1 |
On 04/06/2016 01:34 AM, Duncan wrote: |
2 |
> Richard Yao posted on Wed, 06 Apr 2016 00:15:58 -0400 as excerpted: |
3 |
> |
4 |
> |
5 |
>>> On Apr 4, 2016, at 9:19 PM, William Hubbs <williamh@g.o> wrote: |
6 |
>>> |
7 |
>>> All, |
8 |
>>> |
9 |
>>> I thought that since the usr merge is coming up again, and since I lost |
10 |
>>> track of the message where it was brought up, I would open a new thread |
11 |
>>> to discuss it. |
12 |
>>> |
13 |
>>> When it came up before, some were saying that the /usr merge violates |
14 |
>>> the fhs. I don't remember the specifics of what the claim was at the |
15 |
>>> time, (I'm sure someone will point it out if it is still a concern). |
16 |
>> |
17 |
>> Here are the violations: |
18 |
>> |
19 |
>> http://refspecs.linuxfoundation.org/FHS_3.0/ |
20 |
> fhs-3.0.html#binEssentialUserCommandBinaries |
21 |
>> |
22 |
>> http://refspecs.linuxfoundation.org/FHS_3.0/ |
23 |
> fhs-3.0.html#sbinSystemBinaries |
24 |
>> |
25 |
>> http://refspecs.linuxfoundation.org/FHS_3.0/ |
26 |
> fhs-3.0.html#libEssentialSharedLibrariesAndKern |
27 |
> |
28 |
> (Those links are wrapped and I'm not bothering to jump thru the hoops to |
29 |
> unwrap them, since readers can either unwrap them manually or refer to |
30 |
> the parent post I'm quoting for the unwrapped versions.) |
31 |
> |
32 |
> If those are the "violations", then putting everything in /usr and making |
33 |
> the /bin and /sbin locations symlinks isn't going to be a problem, since |
34 |
> /bin and /sbin are specifically allowed to contain symlinks to the |
35 |
> executables, instead of the executables themselves, and if the dirs |
36 |
> themselves are symlinks to the locations in /usr with the files, that |
37 |
> fulfills that requirement. |
38 |
|
39 |
Alexis Ballier pointed out that the following had been added to make |
40 |
this okay: |
41 |
|
42 |
> The following directories, or symbolic links to directories, are |
43 |
required in /. |
44 |
|
45 |
As far as the Single UNIX Specification is concerned, this sort of thing |
46 |
is okay. The Linux Filesystem Hierarchy Standard that further restricts |
47 |
things had not been updated to permit this until mid-2015. |
48 |
|
49 |
> And the requirement for /lib is rather vague, saying only that it |
50 |
> contains the libs linked by the executables in /bin and /sbin. So once / |
51 |
> bin and /sbin are symlinks to the dirs with the executables, /lib (or the |
52 |
> arch-specific alternative libdirs) can be a symlink as well. |
53 |
> |
54 |
> Tho I must say doing the reverse, making either /usr itself or /usr/bin |
55 |
> and /usr/sbin symlinks to the root dirs, as I did here, actually makes |
56 |
> more sense and bends the rules less. |
57 |
|
58 |
I agree, but Solaris picked the other way and RHEL followed. My opinion |
59 |
is that we should support both. Any automated upgrade scripts that do |
60 |
the /usr merge on behalf of users should detect this state and leave it |
61 |
alone. |
62 |
|
63 |
That being said, I am not of the opinion that we should migrate existing |
64 |
installs or drop support for the older layout for a couple reasons. One |
65 |
is that existing installs will see no benefit from this layout change. |
66 |
The other is that supporting the existing installs is necessary so that |
67 |
we can still do QA on them. |
68 |
|
69 |
I suspect breakage will be more likely with the older layout than the |
70 |
newer one. If we end up not migrating existing installs automatically |
71 |
(maybe via a profile change), we might be able to get away with doing |
72 |
the majority of testing with the older one. If we do not want to do that |
73 |
long term, we could always do it for something like a year to minimize |
74 |
the effect on the userbase. |
75 |
|
76 |
A portage QA check could be made to detect the presence of files in both |
77 |
/{bin,sbin,lib,lib64,lib32} and /usr/{bin,sbin,lib,lib64,lib32} to make |
78 |
verifying that packaging does not do anything weird that would |
79 |
negatively affect the newer layout easier when testing with the older |
80 |
layout. |
81 |
|
82 |
The only exception being the linker scripts. There are at least a few of |
83 |
them still around: |
84 |
|
85 |
richard@desktop ~ $ for fA in /lib/*; do |
86 |
> fB=/usr/lib/${fA##*/}; |
87 |
> [[ -f $fA && -f $fB ]] && echo "$fB"; |
88 |
> done |
89 |
/usr/lib/libeinfo.so |
90 |
/usr/lib/libpamc.so |
91 |
/usr/lib/libpam_misc.so |
92 |
/usr/lib/libpam.so |
93 |
/usr/lib/librc.so |
94 |
richard@desktop ~ $ cat /usr/lib/librc.so |
95 |
/* GNU ld script |
96 |
Since Gentoo has critical dynamic libraries in /lib, and the static |
97 |
versions |
98 |
in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, |
99 |
otherwise we |
100 |
run into linking problems. This "fake" dynamic lib is a linker |
101 |
script that |
102 |
redirects the linker to the real lib. And yes, this works in the cross- |
103 |
compiling scenario as the sysroot-ed linker will prepend the real path. |
104 |
|
105 |
See bug https://bugs.gentoo.org/4411 for more info. |
106 |
*/ |
107 |
OUTPUT_FORMAT ( elf64-x86-64 ) |
108 |
GROUP ( /lib64/librc.so ) |
109 |
|
110 |
I am a bit out of date on the status of these. Do we still need them? If |
111 |
we have not already, we could patch GNU ld to eliminate the need for this. |
112 |
|
113 |
> Basically, what the FHS says, at least in the 3.0 version you linked, is |
114 |
> that the executables must be reachable via whatever specific path, but |
115 |
> using symlinks to do it is fine. |
116 |
> |
117 |
> Which means the merge is allowed, as long as symlinks allow the |
118 |
> executables to be reached by their specifically defined paths. And I'm |
119 |
> not aware of anyone seriously proposing that said symlinks be omitted, |
120 |
> so... |
121 |
|
122 |
My mistake. I had not spotted that change in my cursory read. At least |
123 |
we now know that this is not a Linux FHS violation anymore. :) |