1 |
On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol <mikemol@×××××.com> wrote: |
2 |
> On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao <madumlao@×××××.com> wrote: |
3 |
>> On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mikemol@×××××.com> wrote: |
4 |
>>>> or the fact that some udev programs tend to |
5 |
>>>> be located in /usr, |
6 |
>>> |
7 |
>>> |
8 |
>>> That's either a bug with those programs, or a need for architectural |
9 |
>>> improvements within udev. Both plausible answers. |
10 |
>>> |
11 |
>> |
12 |
>> The most obvious architectural improvement being: simply place udev |
13 |
>> where all its dependencies are and all those bugs turn to nothing. |
14 |
>> Which is what the udev guys did. And the part which seems to elude |
15 |
>> everyone is: it isn't even a limitation of the program. It can still |
16 |
>> be installed to /. Heck we could probably make a USE=root-prefix flag |
17 |
>> for udev that installs it to / instead of /usr. |
18 |
> |
19 |
> This came up today on Reddit. I think it's _highly_ relevant. |
20 |
> |
21 |
> http://www.runswift.ly/solving-bugs.html |
22 |
> |
23 |
> Moving into a full dependency on initr* for separate /usr is a 'fix', |
24 |
> not a solution. |
25 |
> |
26 |
|
27 |
This is where you stumble. It's not a fix. It's a WONTFIX. It's a |
28 |
"make a lot of noise so that something else gets fixed because this is |
29 |
outside of our domain and we're not going to be responsible for it as |
30 |
it wasnt our bug in the first place". And that something else happens |
31 |
to be the / and /usr split conflicting with the user programs. |
32 |
|
33 |
If you give the squeaky wheel the grease - as in merge / and /usr - |
34 |
you apply the fix independently of udev, which was simply installed to |
35 |
the /usr prefix. THAT is a solution - one independent of udev and |
36 |
again, does not depend on initr*. You don't have to. |
37 |
|
38 |
>> |
39 |
>>> |
40 |
>>>> |
41 |
>>>> or even just a solid detailed specification on the |
42 |
>>>> precise criteria for inclusion into /. |
43 |
>>> |
44 |
>>> |
45 |
>>> For anyone arguing that / and /usr should be separate, the answer to this is |
46 |
>>> "that ought to be common sense." |
47 |
>>> |
48 |
>>> Since I'm not someone who knows all there is to know about the software and |
49 |
>>> interactions thereof, the most I can say is: |
50 |
>>> |
51 |
>>> * / ought to contain all binaries, libraries and static data necessary for |
52 |
>>> booting beyond the point where / is mounted, and any machine-specific |
53 |
>>> binaries, libraries and static data. |
54 |
>>> * /usr ought to contain all binaries, libraries and static data not |
55 |
>>> necessary for its own mount. |
56 |
>>> |
57 |
>> |
58 |
>> I'm sure you mean well, as did most of the architects of the past, but |
59 |
>> the reality is, this simplistic take on the problem misses out on some |
60 |
>> fundamental issues. Yes, you mention later that the spec just doesn't |
61 |
>> specify what happens in such and such case, and try to trivialize it |
62 |
>> into saying people think that specs should "be able to do their |
63 |
>> thinking for them". But unfortunately, specifying what happens is |
64 |
>> exactly what specs are for! |
65 |
> |
66 |
> Does the term "overspecification" mean anything to you? Specs cannot |
67 |
> and should not specify every possible conceivable related thing. |
68 |
|
69 |
Two things. |
70 |
|
71 |
First, I'm not saying that a spec should specify everything. I am |
72 |
saying, however, that there are specific cases that is within its |
73 |
domain to specify and that it should be specifying. And because those |
74 |
cases generate conflicts, the fact that they aren't is a bug. |
75 |
|
76 |
Second, going back to problem solving in general - just because you |
77 |
can put down in words what you think the problem is, doesn't mean |
78 |
you've mapped out an accurate or even consistent statement of the |
79 |
problem. There really are cases where it's not enough to just give |
80 |
general airy abstractions and rules of thumb to map out a problem, |
81 |
where it isn't obvious that you're running into edge cases until you |
82 |
really look at it deeply, and yes, the / and /usr split is one of |
83 |
them. |
84 |
|
85 |
>> And the "we have a standard" part is effectively not true anymore, on |
86 |
>> the matter of the / and /usr split. That is - what the specification |
87 |
>> says should happen is not happening, on a massive scale, because it |
88 |
>> turns out that it's not that trivial to determine which binaries go in |
89 |
>> / and which go in /usr. |
90 |
> |
91 |
> Give me an example, and I'll describe a reasonably detailed solution. |
92 |
> It would be my pleasure. |
93 |
|
94 |
The most fundamental and relevant one for us Gentoo users is this: |
95 |
- how can /usr be sharable among different hosts if it depends on |
96 |
libraries in /? |
97 |
|
98 |
""" |
99 |
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY |
100 |
|
101 |
Purpose |
102 |
|
103 |
/usr is the second major section of the filesystem. /usr is shareable, |
104 |
read-only data. That means that /usr should be shareable between |
105 |
various FHS-compliant hosts and must not be written to. Any |
106 |
information that is host-specific or varies with time is stored |
107 |
elsewhere. |
108 |
""" |
109 |
|
110 |
Many distros place fundamental libraries that many programs in /usr |
111 |
depend on in /lib. Especially bad for Gentoo - libraries in /lib may |
112 |
be recompiled as same-version variants if you want to change the USE |
113 |
flags, resulting in clients that don't synchronously recompile their |
114 |
own libraries in /lib to both silently and noisily fail. |
115 |
|
116 |
In other words, many programs in /usr in practice are functionally |
117 |
inseparable from the libraries in /, conflicting with the notion that |
118 |
they were properly shared in the first place. |
119 |
|
120 |
Compare this with the alternate spec that /usr contains both the |
121 |
programs and the libraries. In which case there is no possibility of |
122 |
the programs being out of sync with the libraries. From a maintainance |
123 |
perspective, this reduces the number of points of failure in upgrading |
124 |
the central NFS share. |
125 |
|
126 |
Please note, though, that the / vs /usr issue is a bigger thing after |
127 |
all than udev, and only happens to be a udev-centric discussion |
128 |
because it's one of the most obvious cases of the spec going awry. |
129 |
|
130 |
>> * some teasers: |
131 |
>> [1] udev rules themselves being a case in point. I mean, do the |
132 |
>> requisite binaries belong in /? |
133 |
> |
134 |
> Udev is a dispatcher. Actually, in substance, it's a piece of the |
135 |
> kernel that resides in userland; it exists because it was decided back |
136 |
> around the time of devfs that what devfs was doing is something that |
137 |
> ought to be outside the kernel. In reality, it's effectively been a |
138 |
> userland kernel-support process its entire life. |
139 |
> |
140 |
> What should probably happen is that udev should be fixed to defer |
141 |
> hotplug events until a rules file is able to sucessfully handle it. |
142 |
|
143 |
This is an interesting idea for a fix for the udev subproblem. However |
144 |
again note that the / and /usr split/merge is a bigger thing than the |
145 |
issues that just happen to manifest in udev. Perhaps right now they're |
146 |
giving up on it because they'd rather not waste time fixing a sub |
147 |
problem when fixing the / and /usr split fixes udev with less effort. |
148 |
|
149 |
> And rules files should perform sanity checking and feedback in the |
150 |
> form of "WTF? No, I can't do that yet. Wake me later." |
151 |
|
152 |
$ equery belongs udev/rules.d/|wc -l |
153 |
36 |
154 |
|
155 |
On just my system, 36 different packages and god knows how many |
156 |
different upstreams / maintainers write to udev/rules.d. And that's |
157 |
Gentoo. How about Fedora. How about Red Hat. How about Debian, Ubuntu |
158 |
and god knows how many packages and distros that nobody can guarantee |
159 |
is going to use entirely new syntax. |
160 |
|
161 |
Face it - the udev guys are not going to be in control of whoever |
162 |
writes the rules. Yes, having wait / dependencies in udev might be a |
163 |
neat feature, but there's no guarantee they'll be implemented because |
164 |
they're not part of udev itself. |
165 |
|
166 |
On the other hand you can just edit the system so that the _default |
167 |
setting_ makes it unnecessary to specify dependencies for like 99.xx% |
168 |
of programs out there. |
169 |
|
170 |
> systemd does |
171 |
> something interesting with its "After" clause; that makes perfect |
172 |
> sense. And that's why I asked Canek why one couldn't write a systemd |
173 |
> service file to treat /usr as a service |
174 |
|
175 |
Again, it's not enough to have just a passing understanding of the |
176 |
problem and talk airy abstractions about solutions. You really have to |
177 |
have an understanding of the problem space. |
178 |
|
179 |
systemd, for similar reasons to udev, is installed to /usr by default. |
180 |
This means that systemd won't even be runnable if /usr isn't |
181 |
available, so it won't even be possible to treat /usr as a service. So |
182 |
what you're saying makes no sense as far as typical systemd |
183 |
installations are involved. |
184 |
|
185 |
Now, if you installed systemd to / instead of to /usr, then yes you |
186 |
could create a /usr service which everything else would be dependent |
187 |
on. But you'd conspicuously make almost everything useful it does |
188 |
dependent on /usr, challenging the assumption that it should be |
189 |
separate in the first place. You would, for example, force |
190 |
90-something percent of your unit files to have an extra dependency |
191 |
line that smells like it came from boilerplate kitchen, one of the |
192 |
things systemd was supposed to be designed to minimise. |
193 |
|
194 |
>> [2] fuse-based filesystems allow an administrator the crazy |
195 |
>> possibility of, for example, demanding that /home be an ssh |
196 |
>> connection. Should the ssh client belong in /? ftp? substitute any |
197 |
>> arbitrary client program. |
198 |
> |
199 |
> System dependent binaries and libraries aren't commonly placed in |
200 |
> /home. Your better argument would have been fuse-mounted /usr...in |
201 |
> which case it would be the administrator's responsibility to ensure |
202 |
> said arbitrary client program is present in /bin, and its libraries in |
203 |
> /lib. |
204 |
|
205 |
It's misleading to think that /home being in ssh is an issue, because |
206 |
the point is that the purpose of the root filesystem is: |
207 |
|
208 |
"To boot a system, enough must be present on the root partition to |
209 |
mount other filesystems. This includes utilities, configuration, boot |
210 |
loader information, and other essential start-up data." |
211 |
|
212 |
In other words, if /home is one of the "other filesystems" tools for |
213 |
mounting it should, according to FHS, be in the root filesystem. |
214 |
You're confusing that with the idea binaries are essential. And by the |
215 |
way, if you had emacs-daemon as an init service, it would depend on |
216 |
/home being mounted to be able to read the user's startup, or other |
217 |
similar things like that, so your system would not start up completely |
218 |
unless you had /home mounted. |
219 |
|
220 |
Now you say that it's alright, in this case, the sysad makes ssh |
221 |
available at /bin. But this undermines the primary FHS rationale: for |
222 |
binaries to be in _predictable_ locations for both the sysad AND the |
223 |
software packager. |
224 |
|
225 |
To implement this, then, as either the user / software packager / |
226 |
distro maintainer, I now have to do an intelligent check on /etc/fstab |
227 |
to determine that no filesystems are mounted on fuse. This demands, of |
228 |
course, a table of possible filesystem names and the corresponding |
229 |
client programs (currently not codified), plus that check to |
230 |
/etc/fstab. So the spec _fails to achieve its goal_ for systems where |
231 |
table of client-fuse mappings is not codified: practically all of |
232 |
them. |
233 |
|
234 |
Compare: if all executables were in /usr FHS would have no problem |
235 |
locating the client binaries, because they're all in the same place. |
236 |
|
237 |
> |
238 |
>> [3] a fuse-based filesystem depends on a local network service being |
239 |
>> started. For example, someone writes a crazy fuse mysql browser that |
240 |
>> also is coincidentally mounted at boot time. Should the mysqld service |
241 |
>> belong in /? ldap? substitute any arbitrary server program. |
242 |
> |
243 |
> I seriously cannot imagine anyone doing this except as a prank. The |
244 |
> only similar case I can think of would have the db server on a |
245 |
> separate machine. |
246 |
|
247 |
Well I did say he was crazy ;) |
248 |
|
249 |
> |
250 |
> And if an administrator decides to do this, it's his responsibility to |
251 |
> make sure mysqld is located in /bin, its libraries are in /lib...and |
252 |
> he's got to find some place other than /var for his database! By this |
253 |
> point, you've gone so far into reducto ad absurdum I honestly can't |
254 |
> imagine anyone apart from someone who has absolutely _no_ idea what |
255 |
> they're doing landing themselves in that situation. |
256 |
> |
257 |
|
258 |
More or less same as above. Since the admin is now manually moving |
259 |
things around, the spec _fails to achieve its goal_. |
260 |
|
261 |
Compare: if all executables were in /usr FHS would have no problem |
262 |
locating the server binaries, because they're all in the same place. |
263 |
|
264 |
>> [4] /root (which is why it's separated from /home) contains docs and |
265 |
>> custom utilities used by root user for recovery. Unfortunately, |
266 |
>> there's a lot of perl scripts there specifically for doing filesystem |
267 |
>> checks / reports. Should perl be in in /? substitute any scripting |
268 |
>> language. |
269 |
> |
270 |
> You quoted FHS. I'll quote it back to you: |
271 |
> |
272 |
> "/usr, /opt, and /var are designed such that they may be located on |
273 |
> other partitions or filesystems." |
274 |
> |
275 |
> /root is ridiculously out of the question. /home isn't defended by the |
276 |
> spec, but it's commonly enough separated that it's difficult to |
277 |
> imagine someone making that error twice. |
278 |
|
279 |
/root is the home directory of the root user. If it's not available |
280 |
there, it defaults to the root directory (/). The point being the root |
281 |
user has its own storage that defaults to the root directory, |
282 |
independent of /home or whatnot. |
283 |
|
284 |
http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1037 |
285 |
|
286 |
One good reason why it's separated from /home is because the root user |
287 |
may download or store his own stuff there relevant to fixing that |
288 |
machine. For example, post-install notes are often placed in /root, |
289 |
which detail which packages were selected upon installation. Or while |
290 |
performing lengthy system maintainance, the sysad may write down their |
291 |
upgrade notes, or snip relevant tcpdumps, or what-have-you and store |
292 |
them in the /root directory while the /home directory is unavailable. |
293 |
|
294 |
It is very conceivable for the /root directory to contain perl scripts |
295 |
or whatever the sysad has downloaded in his adventures to grep through |
296 |
his logs and find out what the heck is going on in his system and/or |
297 |
repair it. |
298 |
|
299 |
Should perl be in / or /usr? |
300 |
|
301 |
Again compare: if all executables were in /usr FHS would have no |
302 |
problem locating perl. |
303 |
|
304 |
> What's funny is the gratuitous misreading of the spec that exists, the |
305 |
> anticipation that it would explicitly state more than it does, the |
306 |
> weak technical arguments (so far) in favor of merging / and /usr, and |
307 |
> the dogmatic defense of the merge. |
308 |
|
309 |
You have to think the individual cases through ;) |
310 |
|
311 |
> |
312 |
> With a system such as portage, it should be entirely possible (with |
313 |
> few code changes) to configure installation targets (/ vs /usr) on a |
314 |
> per-package basis, and have that trickle down the dependency chain. |
315 |
|
316 |
Yes, that should be. In fact I think that's the cleanest way to push |
317 |
through so far. Just add a USE=prefix-root to udev. |
318 |
-- |
319 |
This email is: [ ] actionable [ ] fyi [x] social |
320 |
Response needed: [ ] yes [x] up to you [ ] no |
321 |
Time-sensitive: [ ] immediate [ ] soon [x] none |