1 |
On Tue, Jul 17, 2012 at 05:20:13PM -0400, Richard Yao wrote: |
2 |
> An often cited benefit of the /usr merge is the ability to put |
3 |
> everything but /etc on NFS and for that reason, we need to force an |
4 |
> initramfs on people happily using /usr without it. |
5 |
|
6 |
This is not quite correct. The initramfs is required because of [1]. |
7 |
|
8 |
> Interestingly, the /usr merge changes made to genkernel permit us to |
9 |
> mount /etc from a genkernel-built initramfs by putting /etc on a |
10 |
> separate mount point in fstab and then doing `echo /etc >> |
11 |
> /etc/initramfs.mounts`. |
12 |
|
13 |
That doesn't negate putting /usr on nfs and making it possible for |
14 |
different hosts to share it. |
15 |
|
16 |
> Some people claim that the current approach is somehow broken by citing |
17 |
> Bluetooth keyboards. However, what makes that work is adopting an |
18 |
> initramfs and that does *not* require moving files into /usr. If people |
19 |
> do not want an initramfs, they can simply not have a separate /usr. The |
20 |
> /usr merge gives nothing to people using bluetooth while the /usr merge |
21 |
> will break systems of non-bluetooth users. |
22 |
|
23 |
I don't see what bluetooth has to do with anything other than with the |
24 |
'separate usr is broken' document which is a separate issue. |
25 |
|
26 |
> I have been told that moving everything into /usr would be easy for us |
27 |
> because Arch Linux did it and they are a rolling distribution too. Arch |
28 |
> Linux does all-or-nothing upgrades. They do not offer the ability for |
29 |
> their users to choose to use older versions of software and we will not |
30 |
> be able to move everything into /usr without breaking existing systems |
31 |
> that boot without issues now. |
32 |
|
33 |
This issue is not completely flushed out with the upstream folks for |
34 |
udev yet, and either way, it will be addressed in our version of udev. |
35 |
|
36 |
> I have also been told that the /usr merge is necessary because upstream |
37 |
> will force it on us. Interestingly, most of @system on Gentoo Linux is |
38 |
> GNU software, which would need to stop supporting things in / in order |
39 |
> for that to happen. As far ass I know, systemd does not work on GNU HURD |
40 |
> and it would be incapable of functioning if the GNU project made this |
41 |
> change. Hell will freeze long before that happens. |
42 |
|
43 |
This is basically not relevant since we do not support HURD. |
44 |
|
45 |
> The only thing that might require a merge is systemd and it is not in |
46 |
> @system. If we offered users the ability to choose rc systems, we would |
47 |
> still be supporting baselayout-1's rc system. If we start now, we should |
48 |
> bring that back. |
49 |
|
50 |
We offer several rc systems in the tree, but I don't know how up to |
51 |
date they are. Either way, bringing back bl1 is not a relevant |
52 |
argument, because it is not compatible with OpenRC. |
53 |
|
54 |
> With that said, there is a great deal of FUD being spread by the systemd |
55 |
> developers and I see no reason for us to accept it. We would be breaking |
56 |
> users' systems for no gain other than to make the systemd developers |
57 |
> happy. Their refusal to permit udev to be built separately from systemd |
58 |
> demonstrated complete disdain for Gentoo Linux. Why should we let them |
59 |
> dictate how we design our distribution at our users' expense? |
60 |
|
61 |
I think we can do the /usr merge in a way that won't break systems; I am |
62 |
looking into that possibility. I am not interested in breaking systems. |
63 |
|
64 |
> Lastly, don't tell me to read systemd's case for why we should break |
65 |
> people's systems. I have read it and I find it flawed. There is |
66 |
> absolutely no need for us to make this change. |
67 |
|
68 |
Without elaboration on why you find their case flawed, this sounds |
69 |
like the typical, "if it isn't broke, don't fix it" argument. |
70 |
While that has merrit, if there are advantages to doing |
71 |
something, like I think there would be to doing the /usr merge, it may |
72 |
be worth the transition, especially if we can make it as smooth as |
73 |
possible. |
74 |
|
75 |
William |