1 |
On Sat, Dec 29, 2012 at 01:16:34AM +0800, Mark David Dumlao wrote: |
2 |
> TLDR: FHS is unrealistic about its promises. if we move our binaries / |
3 |
> libraries to /usr and work it to make sure /usr is mounted, we will |
4 |
> better serve FHS goals and also happen to fix some systemic, but |
5 |
> silent bugs. |
6 |
> |
7 |
> |
8 |
> On Fri, Dec 28, 2012 at 12:20 PM, Michael Mol <mikemol@×××××.com> wrote: |
9 |
> > On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao <madumlao@×××××.com> |
10 |
> > wrote: |
11 |
> >> Second, going back to problem solving in general - just because you |
12 |
> >> can put down in words what you think the problem is, doesn't mean |
13 |
> >> you've mapped out an accurate or even consistent statement of the |
14 |
> >> problem. There really are cases where it's not enough to just give |
15 |
> >> general airy abstractions and rules of thumb to map out a problem, |
16 |
> >> where it isn't obvious that you're running into edge cases until you |
17 |
> >> really look at it deeply, and yes, the / and /usr split is one of |
18 |
> >> them. |
19 |
> > |
20 |
> > So let's look at it deeply, since nobody else will. I'm game. This is the |
21 |
> > most detailed technical discussion of the problem anyone's cared to |
22 |
> > actually have, as far as I've been able to observe. |
23 |
> |
24 |
> For the purposes of clarity I'm going to compare two competing |
25 |
> standards, which I will be identifying as follows: |
26 |
> |
27 |
> s1) "FHS", or "plain FHS", based on FHS2.3, as identified in |
28 |
> http://www.pathname.com/fhs/pub/fhs-2.3.html |
29 |
> s2) "merged FHS", or "merged standard", based on FHS2.3 as above, but |
30 |
> with the caveat that all binaries and libraries are placed in /usr |
31 |
> instead of being split between /usr and /, as described by |
32 |
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge |
33 |
> |
34 |
> It will be helpful to examine how each system reacts to strange cases |
35 |
> that challenge FHS. |
36 |
> |
37 |
> I think some of the following considerations are helpful in |
38 |
> determining which one works better. Whichever one is emphasized |
39 |
> conspicuously depends on which systems you're interested in |
40 |
> maintaining, how many people are using them, your personal taste, |
41 |
> sense of justice, etc. Perhaps you could add some of your own. |
42 |
> g1) Primary FHS purpose: software/users can predict location of |
43 |
> installed files and directories |
44 |
> g2) make distro maintainers' job easier |
45 |
> g3) make sysads' job easier |
46 |
> g4) it does not directly conflict with general practice |
47 |
> |
48 |
> It is my contention that in all goals, merged FHS is better than plain |
49 |
> FHS. Secondly, it is also my contention that plain FHS with a separate |
50 |
> /usr does not give enough information to reliably satisfy its own |
51 |
> primary goal (g1). Back to the cases below. |
52 |
> |
53 |
> |
54 |
> |
55 |
> ========================================= |
56 |
> === FUNDAMENTAL PROBLEM: / and /usr desync === |
57 |
> ========================================= |
58 |
> Thesis: FHS promise of /usr being sharable is not really deliverable |
59 |
> unless it contains the libraries in /. |
60 |
> |
61 |
> >>>> And the "we have a standard" part is effectively not true anymore, on |
62 |
> >>>> the matter of the / and /usr split. That is - what the specification |
63 |
> >>>> says should happen is not happening, on a massive scale, because it |
64 |
> >>>> turns out that it's not that trivial to determine which binaries go in |
65 |
> >>>> / and which go in /usr. |
66 |
> >>> |
67 |
> >>> Give me an example, and I'll describe a reasonably detailed solution. |
68 |
> >>> It would be my pleasure. |
69 |
> >> |
70 |
> >> The most fundamental and relevant one for us Gentoo users is this: |
71 |
> >> - how can /usr be sharable among different hosts if it depends on |
72 |
> >> libraries in /? |
73 |
> >> |
74 |
> >> """ |
75 |
> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY |
76 |
> >> |
77 |
> >> Purpose |
78 |
> >> |
79 |
> >> /usr is the second major section of the filesystem. /usr is shareable, |
80 |
> >> read-only data. That means that /usr should be shareable between |
81 |
> >> various FHS-compliant hosts and must not be written to. Any |
82 |
> >> information that is host-specific or varies with time is stored |
83 |
> >> elsewhere. |
84 |
> >> """ |
85 |
> >> |
86 |
> >> Many distros place fundamental libraries that many programs in /usr |
87 |
> >> depend on in /lib. Especially bad for Gentoo - libraries in /lib may |
88 |
> >> be recompiled as same-version variants if you want to change the USE |
89 |
> >> flags, resulting in clients that don't synchronously recompile their |
90 |
> >> own libraries in /lib to both silently and noisily fail. |
91 |
> >> |
92 |
> >> In other words, many programs in /usr in practice are functionally |
93 |
> >> inseparable from the libraries in /, conflicting with the notion that |
94 |
> >> they were properly shared in the first place. |
95 |
> > |
96 |
> > There are certain implicit assumptions made in the spec that are important. |
97 |
> > |
98 |
> > First, it's assumed the binaries are compatible with all the hosts. It's |
99 |
> > assumed you're not sharing s360 binaries with x86 hosts, or sparc binaries |
100 |
> > with ppc hosts. |
101 |
> > |
102 |
> > From there, it's reasonable to assume that the authors of the spec assume |
103 |
> > the administrator to be smart enough to not do things like: |
104 |
> > * Mix compiler versions |
105 |
> > * Mix program compile options |
106 |
> > * Place a dependency on a binary that's going to be missing. |
107 |
> > |
108 |
> > The spec is very, very much a "do what you want within these guidelines; |
109 |
> > don't shoot yourself in the foot" thing, it's very much not a declarative |
110 |
> > bikeshedding of everything related to it. |
111 |
> |
112 |
> Unfortunately, FHS actually does explicitly specify the meaning of shareable. |
113 |
> |
114 |
> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEFILESYSTEM |
115 |
> |
116 |
> """"Shareable" files are those that can be stored on one host and used |
117 |
> on others. "Unshareable" files are those that are not shareable. For |
118 |
> example, the files in user home directories are shareable whereas |
119 |
> device lock files are not.""" |
120 |
> |
121 |
> Here I take the meaning "stored on one host and used on others", in |
122 |
> the case of an executable, to mean "stored on one host and |
123 |
> successfully executed on others". |
124 |
> |
125 |
> I think it is plainly obvious that binaries are not usable on other |
126 |
> hosts unless they come with exact libraries they were compiled for. As |
127 |
> far as the user is concerned, the library and the binary are two parts |
128 |
> of the same thing, except that the library is stored in such a way |
129 |
> that memory / disk space is minimized because it can be loaded |
130 |
> multiple times. |
131 |
> |
132 |
> Following the above reasoning, to properly satisfy plain FHS, basic |
133 |
> libraries such as readline, ncurses, gz, that various programs depend |
134 |
> on should at minimum have _copies_ in /usr. But even with that |
135 |
> satisfied, the client of the /usr share would still need to be |
136 |
> configured to use those copies for the programs in /usr, possibly |
137 |
> independently from its own programs in /. |
138 |
> |
139 |
> You say that the spec assumes that the sysad / distro will not "place |
140 |
> a dependency on a binary that's going to be missing". Placing the |
141 |
> library in /usr as well is the only way guarantee that for arbitrary |
142 |
> /usr clients. |
143 |
> |
144 |
> So compare the following shared NFS /usr setups: |
145 |
> |
146 |
> plain FHS |
147 |
> - some libraries are in /lib, with copies in /usr. |
148 |
> - clients using the /usr share need to be configured to use the |
149 |
> libraries in /usr over the ones in / (specifically only for the |
150 |
> libraries in /usr) |
151 |
> - distro maintainer has to determine whether library belongs in / or |
152 |
> /usr. If it belongs in /, a copy will also be placed in /usr. |
153 |
> - chance that sysad can accidentally unsync a client's / with /usr, |
154 |
> resulting in arbitrary unpredictable failures (hard to tell which |
155 |
> programs will silently segfault!) |
156 |
> |
157 |
> merged FHS |
158 |
> - only one copy of the libraries, all in /usr |
159 |
> - clients using the /usr share automatically use the libraries in /usr |
160 |
> without reconfiguration |
161 |
> - distro maintainer installs all libraries to one location only |
162 |
> - sysad cannot desync / and /usr. |
163 |
> |
164 |
> > If I were doing a shared-/usr-over-NFS setup, here's how I'd do it: |
165 |
> > |
166 |
> > 1) Have two NFS shares for /usr, A and B. |
167 |
> > 2) Have all my clients configured to draw from A. |
168 |
> > 3) Perform my upgrade on B. |
169 |
> > 4) Prepare my upgraded client image matching the data on B. Upgraded client |
170 |
> > image would mount B for /usr. |
171 |
> > 5) Replace my clients targeting A with clients targeting B. |
172 |
> > |
173 |
> > And tick-tock between A and B. Or proceed A->B->C, removing old shares once |
174 |
> > they're no longer needed. |
175 |
> |
176 |
> First, the reason you need this update procedure is that you're |
177 |
> compensating for the point of failure you're introducing with plain |
178 |
> FHS: manually having to sync / and /usr. Which is functionally just |
179 |
> one step of sharing /usr anyways. In other words, the fact of / and |
180 |
> /usr being separated is what's giving you all this extra work. |
181 |
> |
182 |
> Second, since you're doing an image upgrade instead of a system |
183 |
> upgrade, you're also complicating your process by having to either |
184 |
> redo your host-specific files in /etc or being dependent on additional |
185 |
> programs for reconfiguring each client based on mac address. Further |
186 |
> opportunities for accidentally shooting yourself in the foot. |
187 |
> |
188 |
> > |
189 |
> > And in any case, I wouldn't share /usr between images with different roles. |
190 |
> > That way lies madness. |
191 |
> |
192 |
> It might be a weird setup, but it isn't any more invalid than wanting |
193 |
> special performance characteristics out of having /usr separated from |
194 |
> /. |
195 |
> |
196 |
> Consider, for instance, that a classroom of thin clients all shares |
197 |
> the same architecture and compile farm, with some clients wanting to |
198 |
> boot to a "photoshop" class and other clients wanting to boot to a |
199 |
> "office productivity class". Students of each class would have |
200 |
> effectively different roles that might be set in the / image, but |
201 |
> there's no good reason for their software to have to be compiled |
202 |
> twice. |
203 |
> |
204 |
> |
205 |
> |
206 |
> ============================================== |
207 |
> === Where do udev rules belong? And the direction of udev === |
208 |
> ============================================== |
209 |
> Thesis: udev/systemd recommends the /usr merge because it fixes |
210 |
> subtle, silent bugs that nobody else wants to fix. We can have udev / |
211 |
> systemd try to work around these bugs, but right now merging /usr is |
212 |
> an available option. |
213 |
> |
214 |
> >>>> * some teasers: |
215 |
> >>>> [1] udev rules themselves being a case in point. I mean, do the |
216 |
> >>>> requisite binaries belong in /? |
217 |
> >>> |
218 |
> >>> Udev is a dispatcher. Actually, in substance, it's a piece of the |
219 |
> >>> kernel that resides in userland; it exists because it was decided back |
220 |
> >>> around the time of devfs that what devfs was doing is something that |
221 |
> >>> ought to be outside the kernel. In reality, it's effectively been a |
222 |
> >>> userland kernel-support process its entire life. |
223 |
> >>> |
224 |
> >>> What should probably happen is that udev should be fixed to defer |
225 |
> >>> hotplug events until a rules file is able to sucessfully handle it. |
226 |
> >> |
227 |
> >> This is an interesting idea for a fix for the udev subproblem. However |
228 |
> >> again note that the / and /usr split/merge is a bigger thing than the |
229 |
> >> issues that just happen to manifest in udev. Perhaps right now they're |
230 |
> >> giving up on it because they'd rather not waste time fixing a sub |
231 |
> >> problem when fixing the / and /usr split fixes udev with less effort. |
232 |
> > |
233 |
> > When we went from x86 to x86_64, we didn't consider it the processor's fault |
234 |
> > for badly-written packages misbehaving. As we went from 8-bit codepages to |
235 |
> > UTF-8, we didn't consider it UTF-8's fault for badly-written packages |
236 |
> > misbehaving. As we go from IPv4 to IPv6, most don't consider it IPv6's fault |
237 |
> > when packages start misbehaving. |
238 |
> > |
239 |
> > We say the package needs to be fixed. |
240 |
> |
241 |
> """...when fixing the / and /usr split fixes udev with less effort.""" |
242 |
> |
243 |
> > |
244 |
> > So what on earth makes this different? |
245 |
> |
246 |
> I think an analogy with programming languages makes this clear. There |
247 |
> are a lot of people that use terrible PHP security practices, and I'm |
248 |
> probably one of them on bad days. That doesn't mean that PHP is buggy. |
249 |
> |
250 |
> Yes, the delivered software, in the end, still needs to be fixed. |
251 |
> |
252 |
> Now the PHP devs have the ability to "fix" those bugs by twiddling the |
253 |
> default settings / behavior of PHP. Those things "fix" the bug by |
254 |
> changing PHP or its settings. OR they can add language features that, |
255 |
> if used correctly, will fix the bugs. Ditto udev. The udev guys can |
256 |
> twiddle the default settings / behavior of it to "fix" the bugs in the |
257 |
> udev rules. Or they can add udev logic that makes the bugs go away. |
258 |
> |
259 |
> Something _is_ special when you're talking about language features. |
260 |
> How much software out there is still using deprecated features in PHP |
261 |
> 4.x / 3.x? Heck, deprecated features in HTML4? |
262 |
> |
263 |
> It is a fact of life that "waiting for other people to implement a fix |
264 |
> on their broken software", in general, doesn't work. If there's a big |
265 |
> enough majority following some behavior, it's better to change the |
266 |
> default behavior to fix the bug. |
267 |
> |
268 |
> Which the merged /usr already does. Yes, it'd be nice to have extra |
269 |
> udev logic for detecting that rules can't execute yet. It isn't |
270 |
> needed, though, if you merge / and /usr. So hats off to eudev for |
271 |
> perhaps their most obvious coding target. |
272 |
> |
273 |
> > While I understand why *systemd* |
274 |
> > should care about badly-written packages with cross-mount-point |
275 |
> > dependencies, I don't understand why udev should, or why udev's direction so |
276 |
> > be so *completely* subsumed by systemd's direction. |
277 |
> |
278 |
> Because it fixes the same bugs. |
279 |
> |
280 |
> >> |
281 |
> >> On the other hand you can just edit the system so that the _default |
282 |
> >> setting_ makes it unnecessary to specify dependencies for like 99.xx% |
283 |
> >> of programs out there. |
284 |
> > |
285 |
> > And why is this a thing that needs to be done except on an as-needed basis? |
286 |
> |
287 |
> BECAUSE IT FIXES BUGS. |
288 |
> |
289 |
> >>> systemd does |
290 |
> >>> something interesting with its "After" clause; that makes perfect |
291 |
> >>> sense. And that's why I asked Canek why one couldn't write a systemd |
292 |
> >>> service file to treat /usr as a service |
293 |
> >> |
294 |
> >> Again, it's not enough to have just a passing understanding of the |
295 |
> >> problem and talk airy abstractions about solutions. You really have to |
296 |
> >> have an understanding of the problem space. |
297 |
> >> |
298 |
> >> systemd, for similar reasons to udev, is installed to /usr by default. |
299 |
> > |
300 |
> > Please, explain these reasons. |
301 |
> |
302 |
> systemd (or some of the stuff it starts) depends on some stuff in |
303 |
> /usr. This makes their placement in /usr technically FHS bugs (for |
304 |
> systemd systems) that the upstreams won't fix. |
305 |
> - locales |
306 |
> - some udev rules |
307 |
> - udisks |
308 |
> - SMART |
309 |
> - PCI database |
310 |
> - USB database |
311 |
> |
312 |
> (Actually some of those seem to kinda _really_ need to be in / |
313 |
> following plain FHS) |
314 |
> |
315 |
> That it happens to work is just either systemd or the relevant |
316 |
> subsystems happening to fail silently and gracefully. |
317 |
> |
318 |
> Placing systemd with all the other stuff fixes those silent failures |
319 |
> in the same way that placing udev with all the other stuff fixes bugs |
320 |
> in udev rules. |
321 |
> |
322 |
> Reference: (Warning: Lennartspeak) |
323 |
> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1337 |
324 |
> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1350 |
325 |
> http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1426 |
326 |
> http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken |
327 |
> |
328 |
> > |
329 |
> > Almost everything useful the kernel does depends on the presence of an init. |
330 |
> > Does that seriously challenge the assumption that init should be separate |
331 |
> > from the kernel? |
332 |
> |
333 |
> Only if the kernel's design goal was to do those useful things itself |
334 |
> (it isn't). One of systemd's design goals is to minimise boilerplate |
335 |
> code in its unit files. |
336 |
> |
337 |
> |
338 |
> |
339 |
> ============================================= |
340 |
> === Hypothetical: does client software belong in / or /usr? === |
341 |
> ============================================= |
342 |
> Thesis: we cannot predict which programs are needed for mounting |
343 |
> arbitrary filesystems, even though mounting "other filesystems" is |
344 |
> required in the root filesystem in plain FHS. |
345 |
> |
346 |
> >>>> [2] fuse-based filesystems allow an administrator the crazy |
347 |
> >>>> possibility of, for example, demanding that /home be an ssh |
348 |
> >>>> connection. Should the ssh client belong in /? ftp? substitute any |
349 |
> >>>> arbitrary client program. |
350 |
> >>> |
351 |
> >>> System dependent binaries and libraries aren't commonly placed in |
352 |
> >>> /home. Your better argument would have been fuse-mounted /usr...in |
353 |
> >>> which case it would be the administrator's responsibility to ensure |
354 |
> >>> said arbitrary client program is present in /bin, and its libraries in |
355 |
> >>> /lib. |
356 |
> >> |
357 |
> >> It's misleading to think that /home being in ssh is an issue, because |
358 |
> >> the point is that the purpose of the root filesystem is: |
359 |
> > |
360 |
> > Wha? *You're* the one who brought up /home in the first place. |
361 |
> > |
362 |
> >> |
363 |
> >> "To boot a system, enough must be present on the root partition to |
364 |
> >> mount other filesystems. This includes utilities, configuration, boot |
365 |
> >> loader information, and other essential start-up data." |
366 |
> >> |
367 |
> >> In other words, if /home is one of the "other filesystems" tools for |
368 |
> >> mounting it should, according to FHS, be in the root filesystem. |
369 |
> > |
370 |
> > Why would /home be "one of the 'other filesystems' tools for mounting"? You |
371 |
> > made a jump here I seriously don't follow. Are we talking credentials? That |
372 |
> > kind of thing that's usually kept under /etc. |
373 |
> > |
374 |
> |
375 |
> You are misreading the spec. FHS says that the root filesystem needs |
376 |
> to be able to check and mount "other filesystems". This doesn't mean |
377 |
> "the /usr filesystem or any place where executables lie", but "all |
378 |
> other filesystems", including /home. If /home were mounted as a |
379 |
> separate filesystem, then the root filesystem needs to contain |
380 |
> whatever binaries are necessary to mount it, whatever filesystem type |
381 |
> it is. |
382 |
> |
383 |
> It is following this logic that mount.fuse is expected to be found in /sbin. |
384 |
> |
385 |
> It is _contrary_ to the spec that any files mount.fuse depends on is |
386 |
> found outside of the root filesystem. |
387 |
> |
388 |
> As you've misunderstood the spec, I'll be dropping your comments on |
389 |
> this scenario being invalid. |
390 |
> |
391 |
> > I'm frankly unfamiliar with emacs-daemon, but (from what you say), it's |
392 |
> > either broken, or was never, ever intended to be run as an init service. |
393 |
> > |
394 |
> |
395 |
> I'll just drop this as it's not essential to the argument |
396 |
> http://www.emacswiki.org/emacs/EmacsAsDaemon |
397 |
> |
398 |
> |
399 |
> >> |
400 |
> >> Now you say that it's alright, in this case, the sysad makes ssh |
401 |
> >> available at /bin. But this undermines the primary FHS rationale: for |
402 |
> >> binaries to be in _predictable_ locations for both the sysad AND the |
403 |
> >> software packager. |
404 |
> > |
405 |
> > The sysad controls the package manager. Regardless of the distribution, |
406 |
> > package placement should _always_ be done via the package manager. This is |
407 |
> > why every package management system that exists is accompanied with a tool |
408 |
> > for importing other package management systems' packages. Including binary |
409 |
> > and source tarballs. |
410 |
> > |
411 |
> |
412 |
> Following this, for any distro to correctly FHS, there needs to be a |
413 |
> package manager switch to copy arbitrary packages (and dependent |
414 |
> libraries) from /usr to /. As of yet not implemented. |
415 |
> |
416 |
> >> Compare: if all executables were in /usr FHS would have no problem |
417 |
> >> locating the client binaries, because they're all in the same place. |
418 |
> > |
419 |
> > And defeats existing functional systems without valid purpose. |
420 |
> |
421 |
> What does it mean to "defeat existing functional systems"? Creating a |
422 |
> single merged FHS system on your network will make your other machines |
423 |
> explode? |
424 |
> |
425 |
> There is an upgrade path from plain FHS to merged FHS (copy and |
426 |
> symlink). I'd know, because I've done it on my box. |
427 |
> |
428 |
> |
429 |
> So compare the following setups with strange and unpredictable new |
430 |
> FUSE filesystems: |
431 |
> |
432 |
> plain FHS |
433 |
> - without knowledge of all fuse filesystems installed on the machine, |
434 |
> the sysad cannot determine if a binary should be in / or /usr |
435 |
> - binaries moved to / have the chance of confusing arbitrary sysads / |
436 |
> maintainance scripts that hardcode path /usr/bin |
437 |
> - package managers need a new unimplemented feature that tells |
438 |
> programs to be moved to /bin |
439 |
> - programs moved to / will also need _copies_ of requisite libraries |
440 |
> in /, independent of libraries in /usr |
441 |
> |
442 |
> merged FHS |
443 |
> - only one copy of the programs and libraries, all in /usr |
444 |
> - sysads / maintainance scripts will always guess correctly by |
445 |
> guessing /usr/bin/foo. |
446 |
> - no need to change any package managers |
447 |
> |
448 |
> |
449 |
> |
450 |
> ============================================= |
451 |
> === Hypothetical: does server software belong in / or /usr? === |
452 |
> ============================================= |
453 |
> Thesis: Just as you cannot determine which client software is needed |
454 |
> for mounting arbitrary filesystems, neither can you determine which |
455 |
> server software will be the dependency of some filesystem. |
456 |
> |
457 |
> >>>> [3] a fuse-based filesystem depends on a local network service being |
458 |
> >>>> started. For example, someone writes a crazy fuse mysql browser that |
459 |
> >>>> also is coincidentally mounted at boot time. Should the mysqld service |
460 |
> >>>> belong in /? ldap? substitute any arbitrary server program. |
461 |
> >>> |
462 |
> >>> And if an administrator decides to do this, it's his responsibility to |
463 |
> >>> make sure mysqld is located in /bin, its libraries are in /lib...and |
464 |
> >>> he's got to find some place other than /var for his database! By this |
465 |
> >>> point, you've gone so far into reducto ad absurdum I honestly can't |
466 |
> >>> imagine anyone apart from someone who has absolutely _no_ idea what |
467 |
> >>> they're doing landing themselves in that situation. |
468 |
> >>> |
469 |
> >> |
470 |
> >> More or less same as above. Since the admin is now manually moving |
471 |
> >> things around, the spec _fails to achieve its goal_. |
472 |
> > |
473 |
> > The presumption is that the admin would use the tools available to him to |
474 |
> > achieve his goals in a consistent fashion. We consider it an error for |
475 |
> > packages to be manually installed into /usr/ as opposed to /usr/local. Why |
476 |
> > would you think I wouldn't consider it an error for a package to be manually |
477 |
> > installed into /? |
478 |
> > |
479 |
> > *Anything* an admin does without the knowledge of his package manager is his |
480 |
> > own fault if it blows up in his face. This is why he is provided with a |
481 |
> > package manager in the first place. |
482 |
> > |
483 |
> |
484 |
> As above, the necessary action is unimplemented in any package |
485 |
> managers I know of. |
486 |
> |
487 |
> As you've blown yourself into a tangent avoiding the fundamental |
488 |
> question, this one goes more or less the same as the one with client |
489 |
> software. But I find that you're very myopic in what you are going to |
490 |
> allow in your Unix. Why, in a Plan9-like system it wouldn't be |
491 |
> uncommon for daemons to serve up a number of filesystems, and if |
492 |
> someone crazy enough makes a toy environment with FUSE it's not our |
493 |
> place to stop them from following the standard. |
494 |
> |
495 |
> ===================================== |
496 |
> === Hypothetical: Should sysad tools be in /? === |
497 |
> ===================================== |
498 |
> Thesis: Because the root user's home directory is intended for the |
499 |
> root user to place arbitrary emergency restore tools and information |
500 |
> in, it is possible for the root user to depend on tools that depend on |
501 |
> /usr being mounted. This creates an FHS violation for all those tools |
502 |
> that does not exist in merged FHS. |
503 |
> |
504 |
> >>>> [4] /root (which is why it's separated from /home) contains docs and |
505 |
> >>>> custom utilities used by root user for recovery. Unfortunately, |
506 |
> >>>> there's a lot of perl scripts there specifically for doing filesystem |
507 |
> >>>> checks / reports. Should perl be in in /? substitute any scripting |
508 |
> >>>> language. |
509 |
> >>> |
510 |
> >>> You quoted FHS. I'll quote it back to you: |
511 |
> >>> |
512 |
> >>> "/usr, /opt, and /var are designed such that they may be located on |
513 |
> >>> other partitions or filesystems." |
514 |
> >>> |
515 |
> >>> /root is ridiculously out of the question. /home isn't defended by the |
516 |
> >>> spec, but it's commonly enough separated that it's difficult to |
517 |
> >>> imagine someone making that error twice. |
518 |
> >> |
519 |
> >> /root is the home directory of the root user. If it's not available |
520 |
> >> there, it defaults to the root directory (/). The point being the root |
521 |
> >> user has its own storage that defaults to the root directory, |
522 |
> >> independent of /home or whatnot. |
523 |
> >> |
524 |
> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1037 |
525 |
> >> |
526 |
> >> One good reason why it's separated from /home is because the root user |
527 |
> >> may download or store his own stuff there relevant to fixing that |
528 |
> >> machine. For example, post-install notes are often placed in /root, |
529 |
> >> which detail which packages were selected upon installation. Or while |
530 |
> >> performing lengthy system maintainance, the sysad may write down their |
531 |
> >> upgrade notes, or snip relevant tcpdumps, or what-have-you and store |
532 |
> >> them in the /root directory while the /home directory is unavailable. |
533 |
> > |
534 |
> > Of course. This is why /root as a separate filesystem is ridiculously out of |
535 |
> > the question. |
536 |
> |
537 |
> I _didn't_ say /root was going to be a separate filesystem. I was |
538 |
> _only_ describing /root for the purposes of clarifying why I expect it |
539 |
> to have the following contents: |
540 |
> |
541 |
> >> It is very conceivable for the /root directory to contain perl scripts |
542 |
> >> or whatever the sysad has downloaded in his adventures to grep through |
543 |
> >> his logs and find out what the heck is going on in his system and/or |
544 |
> >> repair it. |
545 |
> >> |
546 |
> >> Should perl be in / or /usr? |
547 |
> > |
548 |
> > Now that is a good question, if only because Perl traditionally _loathes_ |
549 |
> > being in /bin, for its own philosophical reasons. |
550 |
> > |
551 |
> > Now, as a practical matter? WTF are the scripts written in Perl? Or in |
552 |
> > anything other than sh? If they're intended for emergency use, they've got |
553 |
> > some pretty fat dependencies, and should probably be launched from a full |
554 |
> > rescue environment instead. |
555 |
> |
556 |
> The fact that Perl has fat dependencies doesn't mean that it |
557 |
> shouldn't, according to the spec, be placed in /. The fact is, in this |
558 |
> case plain FHS suggests that Perl be in /. It's that ambiguous about |
559 |
> it. This strongly conflicts with the history of Perl and general |
560 |
> practice, in a way that suggests that we'd rather break plain FHS than |
561 |
> follow the general practice (suggesting the plain FHS is in the |
562 |
> wrong). |
563 |
> |
564 |
> > If you need a Cadillac for bootstrapping and emergency maintenance, sure. |
565 |
> > But this is one of those scenarios that experience and good sense teaches |
566 |
> > you to avoid. |
567 |
> |
568 |
> Doesn't help the fact that it still violates plain FHS. |
569 |
> |
570 |
> |
571 |
> |
572 |
> ==================================================== |
573 |
> === Hypothetical: Can we tell portage to install to / instead of /usr? === |
574 |
> ==================================================== |
575 |
> >>> With a system such as portage, it should be entirely possible (with |
576 |
> >>> few code changes) to configure installation targets (/ vs /usr) on a |
577 |
> >>> per-package basis, and have that trickle down the dependency chain. |
578 |
> >> |
579 |
> >> Yes, that should be. In fact I think that's the cleanest way to push |
580 |
> >> through so far. Just add a USE=prefix-root to udev. |
581 |
> > |
582 |
> > Make it default. The change of default to /usr is what's ridiculously stupid |
583 |
> > about the current scenario. |
584 |
> > |
585 |
> > And, frankly, if this is as much an issue as it's described to be, then |
586 |
> > something beyond USE flags is necessary. A different per-package tunable is |
587 |
> > needed. |
588 |
> |
589 |
> I don't think this is going to be trivial to implement, though. Any |
590 |
> package moved to / is going to also need copies of any library |
591 |
> dependencies to /. I only wonder how linking / revdep-rebuild is going |
592 |
> to work. |
593 |
> |
594 |
> |
595 |
> |
596 |
> -- |
597 |
> This email is: [ ] actionable [x] fyi [ ] social |
598 |
> Response needed: [ ] yes [x] up to you [ ] no |
599 |
> Time-sensitive: [ ] immediate [ ] soon [x] none |
600 |
|
601 |
Dang, I got an Excedrin® headache! |
602 |
|
603 |
No, it can't be fixed with NSAID, nor even morphine! It's simply and only able |
604 |
to be fixed (not solved) by Excedrin® ! |
605 |
|
606 |
Now, after the big D, where's that "unsubscribe/ignore this thread" switch? :( |
607 |
-- |
608 |
Happy Penguin Computers >') |
609 |
126 Fenco Drive ( \ |
610 |
Tupelo, MS 38801 ^^ |
611 |
support@×××××××××××××××××××××.com |
612 |
662-269-2706 662-205-6424 |
613 |
http://happypenguincomputers.com/ |
614 |
|
615 |
Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting |