On Thu, Jan 5, 2012 at 5:36 PM, Alex Alexander <firstname.lastname@example.org> wrote:
> If people are really interested in keeping a tight, self contained root,
> we need to:
> - establish a [tight] list of software we consider critical for /
> - fix/patch software in that list so it can run without /usr there
> - create /bin => /usr/bin/ symlinks for above software (simplifies
> things if packages start hardcoding /usr/bin here and there)
> - move everything else in /usr/bin/
You're missing one thing:
- establish a list of all the configurations that will actually work
with this self-contained root
I think this is why there is so much disagreement over whether this is
a good move. If you have a really simple configuration, then the
self-contained root concept works reasonably well (though apparently
we'll have to heavily patch newer versions of udev or abandon it to
However, if you have a very complex configuration the current
self-contained root is already broken and you need an initramfs
anyway. For in-between cases things might work now but that is likely
to change as upstream moves on.
The binary distros don't have users tweaking their kernels and init
scripts, so they basically have to design for worst-case. Gentoo can
get away with designing for more of an average case since we just tell
anybody with a complex case to go read a howto and configure what is
necessary (and we like to do that stuff anyway).
We can choose not to like it, but it sounds like maintaining a
self-contained root for even the typical case will become untenable.
Those who argue that having /usr on a separate partition simply
shouldn't be supported are basically just saying that our
"self-contained root" should include everything in /usr which seems to
defeat the whole point of a "self-contained root" anyway.
It seems to me that the most reasonable approach is to not force the
issue, but not deviate greatly from upstream either. That means
accepting that over time the rootfs will become less and less capable
of working on its own, and immediately improving tools like dracut to
overcome these limitations. Users who can get away with it can avoid
using an initramfs, at least for a time.
Sure, it is all open source, and Gentoo can swim upstream if we REALLY
want to. However, this only works if developers are willing to spend
the time constantly fixing upstream's tools. It sounds to me like the
maintainers of packages like udev/systemd/etc want to actually move in
the same direction as upstream so in practice I don't see that
Now, Gentoo is about choice, so one thing we should try to do as much
as possible is understand the limitations of the various
configurations and make it clear to users when they do and don't need
an initramfs. To be honest, tight coupling worries me more than the
/usr move, since that has a lot more potential to constrain the
choices we can offer our users (which is a great deal of the value
that Gentoo offers). I understand its advantages, but it seems
somewhat contrary to "the unix way."