Gentoo Archives: gentoo-dev

From: Patrick Lauer <patrick@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Date: Sun, 01 Jan 2012 07:33:20
In Reply to: Re: [gentoo-dev] rfc: locations of binaries and separate /usr by "Olivier Crête"
On 01/01/12 15:12, Olivier Crête wrote:
> Hi, > > On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: >> I have been working with robbat2 on solutions to the separate /usr issue >> (That is why I have specifically cc'd him on this email) >> which will allow people to not use an initramfs. If we migrate >> everything off of the root fs to /usr, all of those solutions become >> moot. On the other hand, if we don't migrate, we run the risk of >> eventually having our default configuration not supported by upstream. > I think the general consensus among other distros is that initramfs is > the new /. Many core elements of the Linux system will start installing > themselves in /usr, starting with udev, so we won't have a choice > anyway. Also, I doubt it's currently possible to boot a Gentoo system > without /usr mounted anyway.
"initramfs is the new /" ... and no one asked if maybe that doesn't really make sense? That people are now actively working on forcing one big system partition is annoying, but I really don't see the need to add a layer or two of complexification just because, well, why not.
> >> 1) Start migrating packages along with upstream and have everyone who >> has a separate /usr (including me by the way) start using an initramfs >> of some kind, either dracut or one that we generate specifically for >> gentoo. The reason I suggest the initramfs, is, unfortunately if we >> migrate everything, nothing else would work. > I also don't see a good reason to not adopt dracut,
Make it work and I'll reconsider it, until then genkernel wins by default.
> re-implementing > something that already works and is maintained by a competent upstream > seems wasteful to me. I really don't see why people resist using an > initramfs so much.
What does it add, apart from time to the boot process? For some setups (like my notebook with luks+lvm) there's no reasonable way around it, but on my desktop it's worse than useless.
> > The udev/kmod/systemd/dracut effort to standardise the base userspace of > Linux is probably scary for quite a few Gentoo-ers as it means that the > end result of an installed Gentoo system will be less differentiated > than it was before. But it still is a step in the right direction as > most of these standardized pieces are much better than what we currently > have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 > and unmaintained upstream shows that even a relatively large > distribution like us can't maintain a competitive base system solution,
Eh what? As part of the OpenRC upstream I find it weird that you call it a fiasco when it works better than the other "solutions" and had about 10 commits in the last 48 hours alone. I don't see an advantage in replacing a known-good solution with some random stuff that mostly doesn't work yet just because it's the future.
> adopting the udev/kmod/systemd way will allow us to use all the work > that they are doing and instead concentrate on making a better system. >
"Better" means no lennartware to me. I want to be able to fully debug init script failures, which systemd makes very hard to impossible. On some machines I have changes in the startup that would mean having to hack up something in C and hope that it doesn't crash init for systemd (what the bleeeep?) Please don't try to bring the GnomeOS vision of having MacOS without paying for it to my computing experience ...


Subject Author
Re: [gentoo-dev] rfc: locations of binaries and separate /usr "Olivier Crête" <tester@g.o>
Re: [gentoo-dev] rfc: locations of binaries and separate /usr Enrico Weigelt <weigelt@×××××.de>