1 |
On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao <madumlao@×××××.com> |
2 |
wrote: |
3 |
> On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol <mikemol@×××××.com> wrote: |
4 |
>> On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao <madumlao@×××××.com> |
5 |
wrote: |
6 |
>>> On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mikemol@×××××.com> wrote: |
7 |
>>>>> or the fact that some udev programs tend to |
8 |
>>>>> be located in /usr, |
9 |
>>>> |
10 |
>>>> |
11 |
>>>> That's either a bug with those programs, or a need for architectural |
12 |
>>>> improvements within udev. Both plausible answers. |
13 |
>>>> |
14 |
>>> |
15 |
>>> The most obvious architectural improvement being: simply place udev |
16 |
>>> where all its dependencies are and all those bugs turn to nothing. |
17 |
>>> Which is what the udev guys did. And the part which seems to elude |
18 |
>>> everyone is: it isn't even a limitation of the program. It can still |
19 |
>>> be installed to /. Heck we could probably make a USE=root-prefix flag |
20 |
>>> for udev that installs it to / instead of /usr. |
21 |
>> |
22 |
>> This came up today on Reddit. I think it's _highly_ relevant. |
23 |
>> |
24 |
>> http://www.runswift.ly/solving-bugs.html |
25 |
>> |
26 |
>> Moving into a full dependency on initr* for separate /usr is a 'fix', |
27 |
>> not a solution. |
28 |
>> |
29 |
> |
30 |
> This is where you stumble. It's not a fix. It's a WONTFIX. It's a |
31 |
> "make a lot of noise so that something else gets fixed because this is |
32 |
> outside of our domain and we're not going to be responsible for it as |
33 |
> it wasnt our bug in the first place". And that something else happens |
34 |
> to be the / and /usr split conflicting with the user programs. |
35 |
|
36 |
I understand that. I made that point myself; that the Gentoo dev moved udev |
37 |
into /usr to reduce the bug passing load on himself. |
38 |
|
39 |
> |
40 |
> If you give the squeaky wheel the grease - as in merge / and /usr - |
41 |
> you apply the fix independently of udev, which was simply installed to |
42 |
> the /usr prefix. THAT is a solution - one independent of udev and |
43 |
> again, does not depend on initr*. You don't have to. |
44 |
|
45 |
That's one solution, but the cure is worse than the disease. |
46 |
|
47 |
> |
48 |
>>> |
49 |
>>>> |
50 |
>>>>> |
51 |
>>>>> or even just a solid detailed specification on the |
52 |
>>>>> precise criteria for inclusion into /. |
53 |
>>>> |
54 |
>>>> |
55 |
>>>> For anyone arguing that / and /usr should be separate, the answer to |
56 |
this is |
57 |
>>>> "that ought to be common sense." |
58 |
>>>> |
59 |
>>>> Since I'm not someone who knows all there is to know about the |
60 |
software and |
61 |
>>>> interactions thereof, the most I can say is: |
62 |
>>>> |
63 |
>>>> * / ought to contain all binaries, libraries and static data necessary |
64 |
for |
65 |
>>>> booting beyond the point where / is mounted, and any machine-specific |
66 |
>>>> binaries, libraries and static data. |
67 |
>>>> * /usr ought to contain all binaries, libraries and static data not |
68 |
>>>> necessary for its own mount. |
69 |
>>>> |
70 |
>>> |
71 |
>>> I'm sure you mean well, as did most of the architects of the past, but |
72 |
>>> the reality is, this simplistic take on the problem misses out on some |
73 |
>>> fundamental issues. Yes, you mention later that the spec just doesn't |
74 |
>>> specify what happens in such and such case, and try to trivialize it |
75 |
>>> into saying people think that specs should "be able to do their |
76 |
>>> thinking for them". But unfortunately, specifying what happens is |
77 |
>>> exactly what specs are for! |
78 |
>> |
79 |
>> Does the term "overspecification" mean anything to you? Specs cannot |
80 |
>> and should not specify every possible conceivable related thing. |
81 |
> |
82 |
> Two things. |
83 |
> |
84 |
> First, I'm not saying that a spec should specify everything. I am |
85 |
> saying, however, that there are specific cases that is within its |
86 |
> domain to specify and that it should be specifying. And because those |
87 |
> cases generate conflicts, the fact that they aren't is a bug. |
88 |
|
89 |
The spec also doesn't say anything about /usr/lib vs /usr/lib32 vs |
90 |
/usr/lib64, yet decisions about those can also cause conflicts. I suppose |
91 |
you'd argue that that's also a bug. |
92 |
|
93 |
I already gave you a pretty succinct definition of what I thought the |
94 |
treatment of /usr should be. And you quoted FHS on the subject, which was |
95 |
eerily similar to what I described. Now, further down, you actually raise |
96 |
specific issues. Let's focus on those. |
97 |
|
98 |
> |
99 |
> Second, going back to problem solving in general - just because you |
100 |
> can put down in words what you think the problem is, doesn't mean |
101 |
> you've mapped out an accurate or even consistent statement of the |
102 |
> problem. There really are cases where it's not enough to just give |
103 |
> general airy abstractions and rules of thumb to map out a problem, |
104 |
> where it isn't obvious that you're running into edge cases until you |
105 |
> really look at it deeply, and yes, the / and /usr split is one of |
106 |
> them. |
107 |
|
108 |
So let's look at it deeply, since nobody else will. I'm game. This is the |
109 |
most detailed technical discussion of the problem anyone's cared to |
110 |
actually have, as far as I've been able to observe. |
111 |
|
112 |
> |
113 |
>>> And the "we have a standard" part is effectively not true anymore, on |
114 |
>>> the matter of the / and /usr split. That is - what the specification |
115 |
>>> says should happen is not happening, on a massive scale, because it |
116 |
>>> turns out that it's not that trivial to determine which binaries go in |
117 |
>>> / and which go in /usr. |
118 |
>> |
119 |
>> Give me an example, and I'll describe a reasonably detailed solution. |
120 |
>> It would be my pleasure. |
121 |
> |
122 |
> The most fundamental and relevant one for us Gentoo users is this: |
123 |
> - how can /usr be sharable among different hosts if it depends on |
124 |
> libraries in /? |
125 |
> |
126 |
> """ |
127 |
> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY |
128 |
> |
129 |
> Purpose |
130 |
> |
131 |
> /usr is the second major section of the filesystem. /usr is shareable, |
132 |
> read-only data. That means that /usr should be shareable between |
133 |
> various FHS-compliant hosts and must not be written to. Any |
134 |
> information that is host-specific or varies with time is stored |
135 |
> elsewhere. |
136 |
> """ |
137 |
> |
138 |
> Many distros place fundamental libraries that many programs in /usr |
139 |
> depend on in /lib. Especially bad for Gentoo - libraries in /lib may |
140 |
> be recompiled as same-version variants if you want to change the USE |
141 |
> flags, resulting in clients that don't synchronously recompile their |
142 |
> own libraries in /lib to both silently and noisily fail. |
143 |
> |
144 |
> In other words, many programs in /usr in practice are functionally |
145 |
> inseparable from the libraries in /, conflicting with the notion that |
146 |
> they were properly shared in the first place. |
147 |
|
148 |
There are certain implicit assumptions made in the spec that are important. |
149 |
|
150 |
First, it's assumed the binaries are compatible with all the hosts. It's |
151 |
assumed you're not sharing s360 binaries with x86 hosts, or sparc binaries |
152 |
with ppc hosts. |
153 |
|
154 |
From there, it's reasonable to assume that the authors of the spec assume |
155 |
the administrator to be smart enough to not do things like: |
156 |
* Mix compiler versions |
157 |
* Mix program compile options |
158 |
* Place a dependency on a binary that's going to be missing. |
159 |
|
160 |
The spec is very, very much a "do what you want within these guidelines; |
161 |
don't shoot yourself in the foot" thing, it's very much not a declarative |
162 |
bikeshedding of everything related to it. |
163 |
|
164 |
> |
165 |
> Compare this with the alternate spec that /usr contains both the |
166 |
> programs and the libraries. In which case there is no possibility of |
167 |
> the programs being out of sync with the libraries. From a maintainance |
168 |
> perspective, this reduces the number of points of failure in upgrading |
169 |
> the central NFS share. |
170 |
|
171 |
If I were doing a shared-/usr-over-NFS setup, here's how I'd do it: |
172 |
|
173 |
1) Have two NFS shares for /usr, A and B. |
174 |
2) Have all my clients configured to draw from A. |
175 |
3) Perform my upgrade on B. |
176 |
4) Prepare my upgraded client image matching the data on B. Upgraded client |
177 |
image would mount B for /usr. |
178 |
5) Replace my clients targeting A with clients targeting B. |
179 |
|
180 |
And tick-tock between A and B. Or proceed A->B->C, removing old shares once |
181 |
they're no longer needed. |
182 |
|
183 |
Either that, or do the whole thing flag-day style. |
184 |
|
185 |
And in any case, I wouldn't share /usr between images with different roles. |
186 |
That way lies madness. |
187 |
|
188 |
> |
189 |
> Please note, though, that the / vs /usr issue is a bigger thing after |
190 |
> all than udev, and only happens to be a udev-centric discussion |
191 |
> because it's one of the most obvious cases of the spec going awry. |
192 |
|
193 |
It's a udev-centric discussion right now because the udev+systemd group |
194 |
chose to take the position that the spec was at fault. I'm arguing with you |
195 |
here to show why they're wrong. |
196 |
|
197 |
> |
198 |
>>> * some teasers: |
199 |
>>> [1] udev rules themselves being a case in point. I mean, do the |
200 |
>>> requisite binaries belong in /? |
201 |
>> |
202 |
>> Udev is a dispatcher. Actually, in substance, it's a piece of the |
203 |
>> kernel that resides in userland; it exists because it was decided back |
204 |
>> around the time of devfs that what devfs was doing is something that |
205 |
>> ought to be outside the kernel. In reality, it's effectively been a |
206 |
>> userland kernel-support process its entire life. |
207 |
>> |
208 |
>> What should probably happen is that udev should be fixed to defer |
209 |
>> hotplug events until a rules file is able to sucessfully handle it. |
210 |
> |
211 |
> This is an interesting idea for a fix for the udev subproblem. However |
212 |
> again note that the / and /usr split/merge is a bigger thing than the |
213 |
> issues that just happen to manifest in udev. Perhaps right now they're |
214 |
> giving up on it because they'd rather not waste time fixing a sub |
215 |
> problem when fixing the / and /usr split fixes udev with less effort. |
216 |
|
217 |
When we went from x86 to x86_64, we didn't consider it the processor's |
218 |
fault for badly-written packages misbehaving. As we went from 8-bit |
219 |
codepages to UTF-8, we didn't consider it UTF-8's fault for badly-written |
220 |
packages misbehaving. As we go from IPv4 to IPv6, most don't consider it |
221 |
IPv6's fault when packages start misbehaving. |
222 |
|
223 |
We say the package needs to be fixed. |
224 |
|
225 |
So what on earth makes this different? While I understand why *systemd* |
226 |
should care about badly-written packages with cross-mount-point |
227 |
dependencies, I don't understand why udev should, or why udev's direction |
228 |
so be so *completely* subsumed by systemd's direction. |
229 |
|
230 |
(For the record, I believe systemd likely cares about badly-written |
231 |
packages because of its already extraordinarily sophisticated complex |
232 |
behavior involving extremely high levels of concurrency that *will* make |
233 |
debugging far more difficult. You'll need some amazing advancements in |
234 |
concurrency-bug-detecting tools to cope with the kinds of debugging issues |
235 |
systemd would make the *norm* for rolling distros like Gentoo, Arch or |
236 |
Debian/unstable. Imagine trying to debug concurrency issues that crop up |
237 |
because program A and program B have an unanticipated influence on each |
238 |
other, and a race condition exists because they're launching in parallel. |
239 |
The Linux scheduler and debugging APIs will need to add some means of |
240 |
halting multiple processes at the same time, just to break into the mess!) |
241 |
|
242 |
> |
243 |
>> And rules files should perform sanity checking and feedback in the |
244 |
>> form of "WTF? No, I can't do that yet. Wake me later." |
245 |
> |
246 |
> $ equery belongs udev/rules.d/|wc -l |
247 |
> 36 |
248 |
> |
249 |
> On just my system, 36 different packages and god knows how many |
250 |
> different upstreams / maintainers write to udev/rules.d. And that's |
251 |
> Gentoo. How about Fedora. How about Red Hat. How about Debian, Ubuntu |
252 |
> and god knows how many packages and distros that nobody can guarantee |
253 |
> is going to use entirely new syntax. |
254 |
|
255 |
So? If a package is broken, *it should be fixed*. I keep pounding that |
256 |
point over and over. Shoving crap into an initramfs, or shoving everything |
257 |
into /usr, or merging / and /usr, doesn't _solve_ complexity problems, it |
258 |
_hides_ it. That's the kind of problem I was trying to allude to with my |
259 |
link to that "fix vs solutions" blog post. |
260 |
|
261 |
> |
262 |
> Face it - the udev guys are not going to be in control of whoever |
263 |
> writes the rules. |
264 |
|
265 |
I wouldn't expect them to. And I don't care; it's not *their* |
266 |
responsibility. It's the responsibility of the package maintainer. |
267 |
|
268 |
It seems like everybody is pointing at the udev folks as the people who |
269 |
should implement a solution for other people's broken packages, and this |
270 |
strikes me as bass-ackward. |
271 |
|
272 |
> Yes, having wait / dependencies in udev might be a |
273 |
> neat feature, but there's no guarantee they'll be implemented because |
274 |
> they're not part of udev itself. |
275 |
|
276 |
Perhaps they'll get implemented in eudev. If I had the time, I'd write up |
277 |
the patches myself. The concepts aren't that hard. |
278 |
|
279 |
> |
280 |
> On the other hand you can just edit the system so that the _default |
281 |
> setting_ makes it unnecessary to specify dependencies for like 99.xx% |
282 |
> of programs out there. |
283 |
|
284 |
And why is this a thing that needs to be done except on an as-needed basis? |
285 |
The only answer I can come up with is that the systemd boot process is |
286 |
going to be a royal pain to debug, given its high degree of concurrency. |
287 |
Quite frankly, that's like issuing body armor to everyone in a factory |
288 |
because someone got hit with a piece of broken glass from a beer bottle |
289 |
crushed by a heavy piece of machinery; it's an overreaction that reduces |
290 |
everyone's agility in response to something whose presence was already a |
291 |
violation of policy and good sense. |
292 |
|
293 |
> |
294 |
>> systemd does |
295 |
>> something interesting with its "After" clause; that makes perfect |
296 |
>> sense. And that's why I asked Canek why one couldn't write a systemd |
297 |
>> service file to treat /usr as a service |
298 |
> |
299 |
> Again, it's not enough to have just a passing understanding of the |
300 |
> problem and talk airy abstractions about solutions. You really have to |
301 |
> have an understanding of the problem space. |
302 |
> |
303 |
> systemd, for similar reasons to udev, is installed to /usr by default. |
304 |
|
305 |
Please, explain these reasons. I've described what I believe these reasons |
306 |
to be, but the only reasons given to me so far are that "it makes a bunch |
307 |
of other badly-written or badly-packages programs behave better." I hold |
308 |
that that's a fundamental misplacement of responsibility. |
309 |
|
310 |
> This means that systemd won't even be runnable if /usr isn't |
311 |
> available, so it won't even be possible to treat /usr as a service. So |
312 |
> what you're saying makes no sense as far as typical systemd |
313 |
> installations are involved. |
314 |
> |
315 |
> Now, if you installed systemd to / instead of to /usr, then yes you |
316 |
> could create a /usr service which everything else would be dependent |
317 |
> on. But you'd conspicuously make almost everything useful it does |
318 |
> dependent on /usr, challenging the assumption that it should be |
319 |
> separate in the first place. |
320 |
|
321 |
Almost everything useful the kernel does depends on the presence of an |
322 |
init. Does that seriously challenge the assumption that init should be |
323 |
separate from the kernel? |
324 |
|
325 |
> You would, for example, force |
326 |
> 90-something percent of your unit files to have an extra dependency |
327 |
> line that smells like it came from boilerplate kitchen, one of the |
328 |
> things systemd was supposed to be designed to minimise. |
329 |
|
330 |
The problem with this argument is that it really does come down to a |
331 |
tradeoff largely based in philosophy. It's a question of expressiveness vs |
332 |
a combination of capability-of-completeness and flexibility. |
333 |
|
334 |
And, frankly, if it matters, there are ways to improve the language. Every |
335 |
dependency-aware package manager since the concept existed has had to |
336 |
grapple with all the same problems. This is not a space where new work is |
337 |
needed to come up with something useful, flexible and largely complete. |
338 |
And, frankly, systemd is trying to reinvent it. It's the same as the cycle |
339 |
of invention in everything in software; "A is ugly and complex. Let's write |
340 |
B to be lean, mean and fast." "B isn't flexible enough to handle these use |
341 |
cases we didn't anticipate, but need to support." "B is ugly and complex. |
342 |
Let's write C to be lean, mean and fast." |
343 |
|
344 |
(Heck, before you know it, init system configuration files will be written |
345 |
in Common Lisp. :P ) |
346 |
|
347 |
> |
348 |
>>> [2] fuse-based filesystems allow an administrator the crazy |
349 |
>>> possibility of, for example, demanding that /home be an ssh |
350 |
>>> connection. Should the ssh client belong in /? ftp? substitute any |
351 |
>>> arbitrary client program. |
352 |
>> |
353 |
>> System dependent binaries and libraries aren't commonly placed in |
354 |
>> /home. Your better argument would have been fuse-mounted /usr...in |
355 |
>> which case it would be the administrator's responsibility to ensure |
356 |
>> said arbitrary client program is present in /bin, and its libraries in |
357 |
>> /lib. |
358 |
> |
359 |
> It's misleading to think that /home being in ssh is an issue, because |
360 |
> the point is that the purpose of the root filesystem is: |
361 |
|
362 |
Wha? *You're* the one who brought up /home in the first place. |
363 |
|
364 |
> |
365 |
> "To boot a system, enough must be present on the root partition to |
366 |
> mount other filesystems. This includes utilities, configuration, boot |
367 |
> loader information, and other essential start-up data." |
368 |
> |
369 |
> In other words, if /home is one of the "other filesystems" tools for |
370 |
> mounting it should, according to FHS, be in the root filesystem. |
371 |
|
372 |
Why would /home be "one of the 'other filesystems' tools for mounting"? You |
373 |
made a jump here I seriously don't follow. Are we talking credentials? That |
374 |
kind of thing that's usually kept under /etc. |
375 |
|
376 |
> You're confusing that with the idea binaries are essential. And by the |
377 |
> way, if you had emacs-daemon as an init service, it would depend on |
378 |
> /home being mounted to be able to read the user's startup, or other |
379 |
> similar things like that, so your system would not start up completely |
380 |
> unless you had /home mounted. |
381 |
|
382 |
I'm frankly unfamiliar with emacs-daemon, but (from what you say), it's |
383 |
either broken, or was never, ever intended to be run as an init service. |
384 |
|
385 |
> |
386 |
> Now you say that it's alright, in this case, the sysad makes ssh |
387 |
> available at /bin. But this undermines the primary FHS rationale: for |
388 |
> binaries to be in _predictable_ locations for both the sysad AND the |
389 |
> software packager. |
390 |
|
391 |
The sysad controls the package manager. Regardless of the distribution, |
392 |
package placement should _always_ be done via the package manager. This is |
393 |
why every package management system that exists is accompanied with a tool |
394 |
for importing other package management systems' packages. Including binary |
395 |
and source tarballs. |
396 |
|
397 |
> |
398 |
> To implement this, then, as either the user / software packager /> distro |
399 |
maintainer, I now have to do an intelligent check on /etc/fstab |
400 |
> to determine that no filesystems are mounted on fuse. |
401 |
|
402 |
This doesn't follow, since you haven't explained what you need /home for! |
403 |
Credentials are typically kept under /etc. |
404 |
|
405 |
> This demands, of |
406 |
> course, a table of possible filesystem names and the corresponding |
407 |
> client programs (currently not codified), plus that check to |
408 |
> /etc/fstab. So the spec _fails to achieve its goal_ for systems where |
409 |
> table of client-fuse mappings is not codified: practically all of |
410 |
> them. |
411 |
|
412 |
Irrelevant, because the scenario is invalid. |
413 |
|
414 |
> |
415 |
> Compare: if all executables were in /usr FHS would have no problem |
416 |
> locating the client binaries, because they're all in the same place. |
417 |
|
418 |
And defeats existing functional systems without valid purpose. (Where I |
419 |
hold that presuming responsibility of packages' dependencies is somehow |
420 |
udev/systemd's responsibility, rather than that of the package authors and |
421 |
maintainers, is invalid.) |
422 |
|
423 |
> |
424 |
>> |
425 |
>>> [3] a fuse-based filesystem depends on a local network service being |
426 |
>>> started. For example, someone writes a crazy fuse mysql browser that |
427 |
>>> also is coincidentally mounted at boot time. Should the mysqld service |
428 |
>>> belong in /? ldap? substitute any arbitrary server program. |
429 |
>> |
430 |
>> I seriously cannot imagine anyone doing this except as a prank. The |
431 |
>> only similar case I can think of would have the db server on a |
432 |
>> separate machine. |
433 |
> |
434 |
> Well I did say he was crazy ;) |
435 |
> |
436 |
>> |
437 |
>> And if an administrator decides to do this, it's his responsibility to |
438 |
>> make sure mysqld is located in /bin, its libraries are in /lib...and |
439 |
>> he's got to find some place other than /var for his database! By this |
440 |
>> point, you've gone so far into reducto ad absurdum I honestly can't |
441 |
>> imagine anyone apart from someone who has absolutely _no_ idea what |
442 |
>> they're doing landing themselves in that situation. |
443 |
>> |
444 |
> |
445 |
> More or less same as above. Since the admin is now manually moving |
446 |
> things around, the spec _fails to achieve its goal_. |
447 |
|
448 |
The presumption is that the admin would use the tools available to him to |
449 |
achieve his goals in a consistent fashion. We consider it an error for |
450 |
packages to be manually installed into /usr/ as opposed to /usr/local. Why |
451 |
would you think I wouldn't consider it an error for a package to be |
452 |
manually installed into /? |
453 |
|
454 |
*Anything* an admin does without the knowledge of his package manager is |
455 |
his own fault if it blows up in his face. This is why he is provided with a |
456 |
package manager in the first place. |
457 |
|
458 |
> |
459 |
> Compare: if all executables were in /usr FHS would have no problem |
460 |
> locating the server binaries, because they're all in the same place. |
461 |
|
462 |
Hold off on the compares until we have something useful to compare to. |
463 |
|
464 |
> |
465 |
>>> [4] /root (which is why it's separated from /home) contains docs and |
466 |
>>> custom utilities used by root user for recovery. Unfortunately, |
467 |
>>> there's a lot of perl scripts there specifically for doing filesystem |
468 |
>>> checks / reports. Should perl be in in /? substitute any scripting |
469 |
>>> language. |
470 |
>> |
471 |
>> You quoted FHS. I'll quote it back to you: |
472 |
>> |
473 |
>> "/usr, /opt, and /var are designed such that they may be located on |
474 |
>> other partitions or filesystems." |
475 |
>> |
476 |
>> /root is ridiculously out of the question. /home isn't defended by the |
477 |
>> spec, but it's commonly enough separated that it's difficult to |
478 |
>> imagine someone making that error twice. |
479 |
> |
480 |
> /root is the home directory of the root user. If it's not available |
481 |
> there, it defaults to the root directory (/). The point being the root |
482 |
> user has its own storage that defaults to the root directory, |
483 |
> independent of /home or whatnot. |
484 |
> |
485 |
> http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1037 |
486 |
> |
487 |
> One good reason why it's separated from /home is because the root user |
488 |
> may download or store his own stuff there relevant to fixing that |
489 |
> machine. For example, post-install notes are often placed in /root, |
490 |
> which detail which packages were selected upon installation. Or while |
491 |
> performing lengthy system maintainance, the sysad may write down their |
492 |
> upgrade notes, or snip relevant tcpdumps, or what-have-you and store |
493 |
> them in the /root directory while the /home directory is unavailable. |
494 |
|
495 |
Of course. This is why /root as a separate filesystem is ridiculously out |
496 |
of the question. |
497 |
|
498 |
> |
499 |
> It is very conceivable for the /root directory to contain perl scripts |
500 |
> or whatever the sysad has downloaded in his adventures to grep through |
501 |
> his logs and find out what the heck is going on in his system and/or |
502 |
> repair it. |
503 |
> |
504 |
> Should perl be in / or /usr? |
505 |
|
506 |
Now that is a good question, if only because Perl traditionally _loathes_ |
507 |
being in /bin, for its own philosophical reasons. |
508 |
|
509 |
Now, as a practical matter? WTF are the scripts written in Perl? Or in |
510 |
anything other than sh? If they're intended for emergency use, they've got |
511 |
some pretty fat dependencies, and should probably be launched from a full |
512 |
rescue environment instead. Or the log files should be copied to some place |
513 |
with more featureful tools available. |
514 |
|
515 |
> |
516 |
> Again compare: if all executables were in /usr FHS would have no |
517 |
> problem locating perl. |
518 |
|
519 |
If you need a Cadillac for bootstrapping and emergency maintenance, sure. |
520 |
But this is one of those scenarios that experience and good sense teaches |
521 |
you to avoid. Once-in-a-blue-moon scripts are useful when they're |
522 |
needed--until they blow up because they were written for a version of the |
523 |
language that's incompatible with what's installed. That's why sh-fu is |
524 |
such a vital skill for admins. sh is everywhere. Even where bash isn't. |
525 |
|
526 |
So, I still disagree with your example scenario. |
527 |
|
528 |
> |
529 |
>> What's funny is the gratuitous misreading of the spec that exists, the |
530 |
>> anticipation that it would explicitly state more than it does, the |
531 |
>> weak technical arguments (so far) in favor of merging / and /usr, and |
532 |
>> the dogmatic defense of the merge. |
533 |
> |
534 |
> You have to think the individual cases through ;) |
535 |
|
536 |
I've responded. |
537 |
|
538 |
> |
539 |
>> |
540 |
>> With a system such as portage, it should be entirely possible (with |
541 |
>> few code changes) to configure installation targets (/ vs /usr) on a |
542 |
>> per-package basis, and have that trickle down the dependency chain. |
543 |
> |
544 |
> Yes, that should be. In fact I think that's the cleanest way to push |
545 |
> through so far. Just add a USE=prefix-root to udev. |
546 |
|
547 |
Make it default. The change of default to /usr is what's ridiculously |
548 |
stupid about the current scenario. |
549 |
|
550 |
And, frankly, if this is as much an issue as it's described to be, then |
551 |
something beyond USE flags is necessary. A different per-package tunable is |
552 |
needed. |
553 |
|
554 |
-- |
555 |
:wq |