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