1 |
On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao <madumlao@×××××.com> wrote: |
2 |
> On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mikemol@×××××.com> wrote: |
3 |
>>> or the fact that some udev programs tend to |
4 |
>>> be located in /usr, |
5 |
>> |
6 |
>> |
7 |
>> That's either a bug with those programs, or a need for architectural |
8 |
>> improvements within udev. Both plausible answers. |
9 |
>> |
10 |
> |
11 |
> The most obvious architectural improvement being: simply place udev |
12 |
> where all its dependencies are and all those bugs turn to nothing. |
13 |
> Which is what the udev guys did. And the part which seems to elude |
14 |
> everyone is: it isn't even a limitation of the program. It can still |
15 |
> be installed to /. Heck we could probably make a USE=root-prefix flag |
16 |
> for udev that installs it to / instead of /usr. |
17 |
|
18 |
This came up today on Reddit. I think it's _highly_ relevant. |
19 |
|
20 |
http://www.runswift.ly/solving-bugs.html |
21 |
|
22 |
Moving into a full dependency on initr* for separate /usr is a 'fix', |
23 |
not a solution. |
24 |
|
25 |
> |
26 |
>> |
27 |
>>> |
28 |
>>> or even just a solid detailed specification on the |
29 |
>>> precise criteria for inclusion into /. |
30 |
>> |
31 |
>> |
32 |
>> For anyone arguing that / and /usr should be separate, the answer to this is |
33 |
>> "that ought to be common sense." |
34 |
>> |
35 |
>> Since I'm not someone who knows all there is to know about the software and |
36 |
>> interactions thereof, the most I can say is: |
37 |
>> |
38 |
>> * / ought to contain all binaries, libraries and static data necessary for |
39 |
>> booting beyond the point where / is mounted, and any machine-specific |
40 |
>> binaries, libraries and static data. |
41 |
>> * /usr ought to contain all binaries, libraries and static data not |
42 |
>> necessary for its own mount. |
43 |
>> |
44 |
> |
45 |
> I'm sure you mean well, as did most of the architects of the past, but |
46 |
> the reality is, this simplistic take on the problem misses out on some |
47 |
> fundamental issues. Yes, you mention later that the spec just doesn't |
48 |
> specify what happens in such and such case, and try to trivialize it |
49 |
> into saying people think that specs should "be able to do their |
50 |
> thinking for them". But unfortunately, specifying what happens is |
51 |
> exactly what specs are for! |
52 |
|
53 |
Does the term "overspecification" mean anything to you? Specs cannot |
54 |
and should not specify every possible conceivable related thing. |
55 |
|
56 |
> |
57 |
> However... |
58 |
> |
59 |
>>> |
60 |
>>> Even the FHS is mum on all the |
61 |
>>> extra crap we randomly decide between / and /usr to land in. |
62 |
>> |
63 |
>> |
64 |
>> So fix it. FHS was a document written to say "we have a standard" that |
65 |
>> happened to map almost cleanly to all the implementations of the day. Kinda |
66 |
>> like how SQL mapped "almost cleanly" to the existing RDBMSs that existed |
67 |
>> when it was introduced. Such is how standards documents are born. |
68 |
>> |
69 |
> |
70 |
> Don't forget that FHS is heavily an after-the-fact descriptive |
71 |
> document of what is happening in practice, with heavy "rationale" |
72 |
> sections describing what's going on in the wild. Before you can fix |
73 |
> FHS, you first have to fix the practice, then FHS can get amended to |
74 |
> reflect what's going on. |
75 |
> |
76 |
> And the "we have a standard" part is effectively not true anymore, on |
77 |
> the matter of the / and /usr split. That is - what the specification |
78 |
> says should happen is not happening, on a massive scale, because it |
79 |
> turns out that it's not that trivial to determine which binaries go in |
80 |
> / and which go in /usr. |
81 |
|
82 |
Give me an example, and I'll describe a reasonably detailed solution. |
83 |
It would be my pleasure. |
84 |
|
85 |
> Now that doesn't translate to epic disasters |
86 |
> of biblical proportion, fire and brimstone, rivers and seas boiling, |
87 |
> dogs and cats living together, mass hysteria - because it's just a |
88 |
> collection of hard to pin down "essential" boot programs - but it does |
89 |
> translate to an unsustainable practice in distro development / package |
90 |
> management. |
91 |
> |
92 |
> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM |
93 |
> |
94 |
> """ |
95 |
> Purpose: |
96 |
> The contents of the root filesystem must be adequate to boot, restore, |
97 |
> recover, and/or repair the system. |
98 |
> |
99 |
> To boot a system, enough must be present on the root partition to |
100 |
> mount other filesystems. This includes utilities, configuration, boot |
101 |
> loader information, and other essential start-up data. /usr, /opt, and |
102 |
> /var are designed such that they may be located on other partitions or |
103 |
> filesystems. |
104 |
> |
105 |
> To enable recovery and/or repair of a system, those utilities needed |
106 |
> by an experienced maintainer to diagnose and reconstruct a damaged |
107 |
> system must be present on the root filesystem. |
108 |
> |
109 |
> To restore a system, those utilities needed to restore from system |
110 |
> backups (on floppy, tape, etc.) must be present on the root |
111 |
> filesystem. |
112 |
> """ |
113 |
> |
114 |
> * some teasers: |
115 |
> [1] udev rules themselves being a case in point. I mean, do the |
116 |
> requisite binaries belong in /? |
117 |
|
118 |
Udev is a dispatcher. Actually, in substance, it's a piece of the |
119 |
kernel that resides in userland; it exists because it was decided back |
120 |
around the time of devfs that what devfs was doing is something that |
121 |
ought to be outside the kernel. In reality, it's effectively been a |
122 |
userland kernel-support process its entire life. |
123 |
|
124 |
What should probably happen is that udev should be fixed to defer |
125 |
hotplug events until a rules file is able to sucessfully handle it. |
126 |
And rules files should perform sanity checking and feedback in the |
127 |
form of "WTF? No, I can't do that yet. Wake me later." systemd does |
128 |
something interesting with its "After" clause; that makes perfect |
129 |
sense. And that's why I asked Canek why one couldn't write a systemd |
130 |
service file to treat /usr as a service, and make anything dependent |
131 |
on /usr's presence depend on the /usr "service". That would actually |
132 |
make _sense_. (Canek declined to opine, or even utilize his |
133 |
familiarity with the system to theorize how it could be done or what |
134 |
it would look like. I was disappointed; I was genuinely interested.) |
135 |
|
136 |
> For example, there's a virtualbox udev |
137 |
> rule in /usr that doesn't mount other filesystems or stop udev from |
138 |
> starting. However, given the right race conditions, udev will fail to |
139 |
> start the requisite script because /usr isn't mounted. |
140 |
|
141 |
See above. |
142 |
|
143 |
> [2] fuse-based filesystems allow an administrator the crazy |
144 |
> possibility of, for example, demanding that /home be an ssh |
145 |
> connection. Should the ssh client belong in /? ftp? substitute any |
146 |
> arbitrary client program. |
147 |
|
148 |
System dependent binaries and libraries aren't commonly placed in |
149 |
/home. Your better argument would have been fuse-mounted /usr...in |
150 |
which case it would be the administrator's responsibility to ensure |
151 |
said arbitrary client program is present in /bin, and its libraries in |
152 |
/lib. |
153 |
|
154 |
> [3] a fuse-based filesystem depends on a local network service being |
155 |
> started. For example, someone writes a crazy fuse mysql browser that |
156 |
> also is coincidentally mounted at boot time. Should the mysqld service |
157 |
> belong in /? ldap? substitute any arbitrary server program. |
158 |
|
159 |
I seriously cannot imagine anyone doing this except as a prank. The |
160 |
only similar case I can think of would have the db server on a |
161 |
separate machine. |
162 |
|
163 |
And if an administrator decides to do this, it's his responsibility to |
164 |
make sure mysqld is located in /bin, its libraries are in /lib...and |
165 |
he's got to find some place other than /var for his database! By this |
166 |
point, you've gone so far into reducto ad absurdum I honestly can't |
167 |
imagine anyone apart from someone who has absolutely _no_ idea what |
168 |
they're doing landing themselves in that situation. |
169 |
|
170 |
> [4] /root (which is why it's separated from /home) contains docs and |
171 |
> custom utilities used by root user for recovery. Unfortunately, |
172 |
> there's a lot of perl scripts there specifically for doing filesystem |
173 |
> checks / reports. Should perl be in in /? substitute any scripting |
174 |
> language. |
175 |
|
176 |
You quoted FHS. I'll quote it back to you: |
177 |
|
178 |
"/usr, /opt, and /var are designed such that they may be located on |
179 |
other partitions or filesystems." |
180 |
|
181 |
/root is ridiculously out of the question. /home isn't defended by the |
182 |
spec, but it's commonly enough separated that it's difficult to |
183 |
imagine someone making that error twice. |
184 |
|
185 |
> |
186 |
> The point is not whether _you_ can come up with an answer for _your_ |
187 |
> own case. A _standard_ speaks for everyone that conforms to it. If it |
188 |
> doesn't, or it comes up with conflicting use cases as above, the spec |
189 |
> is broken. |
190 |
|
191 |
The use cases you described, per spec, are broken. The standard, as |
192 |
described, makes my answers to your use case descriptions virtually |
193 |
self-evident. |
194 |
|
195 |
> The fact that edge cases are appearing (and would all |
196 |
> disappear if / and /usr were merged) is a hint that something funny is |
197 |
> going on. |
198 |
|
199 |
What's funny is the gratuitous misreading of the spec that exists, the |
200 |
anticipation that it would explicitly state more than it does, the |
201 |
weak technical arguments (so far) in favor of merging / and /usr, and |
202 |
the dogmatic defense of the merge. |
203 |
|
204 |
With a system such as portage, it should be entirely possible (with |
205 |
few code changes) to configure installation targets (/ vs /usr) on a |
206 |
per-package basis, and have that trickle down the dependency chain. |
207 |
Certainly, many packages with broken build systems won't properly |
208 |
accept --prefix, but that's something that can (and should, and |
209 |
really, must eventually) be fixed. There's also the matter of |
210 |
stability while moving packages between /usr and /, but |
211 |
@preserved-rebuild and subslots should solve that. |
212 |
|
213 |
Now, binary distros? There are solutions to be had. They're more |
214 |
difficult. But most of the binary distros don't care, since they use |
215 |
initrd and update it automatically. |
216 |
|
217 |
-- |
218 |
:wq |