1 |
On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander <wired@g.o> wrote: |
2 |
> If people are really interested in keeping a tight, self contained root, |
3 |
> we need to: |
4 |
> |
5 |
> - establish a [tight] list of software we consider critical for / |
6 |
> - fix/patch software in that list so it can run without /usr there |
7 |
> - create /bin => /usr/bin/ symlinks for above software (simplifies |
8 |
> things if packages start hardcoding /usr/bin here and there) |
9 |
> - move everything else in /usr/bin/ |
10 |
|
11 |
You're missing one thing: |
12 |
|
13 |
- establish a list of all the configurations that will actually work |
14 |
with this self-contained root |
15 |
|
16 |
I think this is why there is so much disagreement over whether this is |
17 |
a good move. If you have a really simple configuration, then the |
18 |
self-contained root concept works reasonably well (though apparently |
19 |
we'll have to heavily patch newer versions of udev or abandon it to |
20 |
sustain this). |
21 |
|
22 |
However, if you have a very complex configuration the current |
23 |
self-contained root is already broken and you need an initramfs |
24 |
anyway. For in-between cases things might work now but that is likely |
25 |
to change as upstream moves on. |
26 |
|
27 |
The binary distros don't have users tweaking their kernels and init |
28 |
scripts, so they basically have to design for worst-case. Gentoo can |
29 |
get away with designing for more of an average case since we just tell |
30 |
anybody with a complex case to go read a howto and configure what is |
31 |
necessary (and we like to do that stuff anyway). |
32 |
|
33 |
We can choose not to like it, but it sounds like maintaining a |
34 |
self-contained root for even the typical case will become untenable. |
35 |
Those who argue that having /usr on a separate partition simply |
36 |
shouldn't be supported are basically just saying that our |
37 |
"self-contained root" should include everything in /usr which seems to |
38 |
defeat the whole point of a "self-contained root" anyway. |
39 |
|
40 |
It seems to me that the most reasonable approach is to not force the |
41 |
issue, but not deviate greatly from upstream either. That means |
42 |
accepting that over time the rootfs will become less and less capable |
43 |
of working on its own, and immediately improving tools like dracut to |
44 |
overcome these limitations. Users who can get away with it can avoid |
45 |
using an initramfs, at least for a time. |
46 |
|
47 |
Sure, it is all open source, and Gentoo can swim upstream if we REALLY |
48 |
want to. However, this only works if developers are willing to spend |
49 |
the time constantly fixing upstream's tools. It sounds to me like the |
50 |
maintainers of packages like udev/systemd/etc want to actually move in |
51 |
the same direction as upstream so in practice I don't see that |
52 |
happening. |
53 |
|
54 |
Now, Gentoo is about choice, so one thing we should try to do as much |
55 |
as possible is understand the limitations of the various |
56 |
configurations and make it clear to users when they do and don't need |
57 |
an initramfs. To be honest, tight coupling worries me more than the |
58 |
/usr move, since that has a lot more potential to constrain the |
59 |
choices we can offer our users (which is a great deal of the value |
60 |
that Gentoo offers). I understand its advantages, but it seems |
61 |
somewhat contrary to "the unix way." |
62 |
|
63 |
Rich |