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

Replies

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>