1 |
On 24-04-2012 22:34:45 -0500, William Hubbs wrote: |
2 |
> Everybody has to live with this stuff couldn't be more true. We are |
3 |
> talking about changes in the linux world that are coming from outside of |
4 |
> gentoo. |
5 |
|
6 |
[snip] |
7 |
|
8 |
> Like I said above, it isn't just the udev maintainers. We aren't talking |
9 |
> about changes to udev. we are talking about changes to the entire |
10 |
> linux ecosystem. |
11 |
|
12 |
[snip] |
13 |
|
14 |
> I too am definitely a proponent of choice. However, I don't feel that |
15 |
> the choice of having /usr on a separate file system without using an |
16 |
> initramfs is a practical one to offer; especially with the /usr merge |
17 |
> coming down the pipe. |
18 |
|
19 |
|
20 |
The great /usr merge. |
21 |
|
22 |
As far as I have understood from previous discussions here, the GnomeOS |
23 |
folks have a vision that constitutes a one thing to rule them all |
24 |
approach. It makes their life (from a binary point of view) easier. |
25 |
|
26 |
- If we want to follow the current trend in desktop systems, we need to |
27 |
follow the GnomeOS vision. |
28 |
- The GnomeOS vision dictates that a vast majority of modules, libraries |
29 |
and programs are available early during boot. They have chosen to |
30 |
expect them to be in /usr, and hence that /usr is availble early |
31 |
during boot. |
32 |
|
33 |
In the past, and it is suggested in the quoted email again, it was |
34 |
claimed that everyone will start installing stuff in /usr, because of |
35 |
the GnomeOS vision. The only proof being brought up back then actually |
36 |
turned out not to be supporting that claim. |
37 |
|
38 |
It was claimed multiple times that recent Solaris would have done "the |
39 |
/usr merge" as well, but to my best understanding, this was based on a |
40 |
misunderstanding of historical Solaris characteristics. IMO UNIX |
41 |
mandates "the /usr merge" not to happen. |
42 |
|
43 |
Clearly, there is a drive to comply to the GnomeOS vision. With the |
44 |
characteristics and tools of Gentoo, this seems to be easy to |
45 |
effectuate. However, people that do not want to go with the GnomeOS |
46 |
vision, are affected by just moving tools to /usr. This is my |
47 |
understanding of where problems arise, and why the council was involved. |
48 |
|
49 |
People that do not want to follow the path of the GnomeOS vision, need |
50 |
to stay with "old" software. Software that we developed ourselves, or |
51 |
that we've been using for a long time to get the systems working as we |
52 |
want. Because of the drive of current maintainers of critical software |
53 |
components to follow the GnomeOS vision, the council has found people |
54 |
willing to keep the current state of software running. This means, that |
55 |
those people who want to move on, following the vision they believe in, |
56 |
can do so, without being forced to do things they don't believe in. |
57 |
|
58 |
In my humble opinion, the essential bit missing here, is where both |
59 |
camps respect each other. That is, not to make it impossible for either |
60 |
camp to follow their vision. |
61 |
I've made suggestions for this in the last council meeting. The options |
62 |
we have as Gentoo -- a remarkable flexible and well controllable |
63 |
source-based distribution -- are numerous. We can have special |
64 |
profiles, introduce new USE-flags, etc. |
65 |
|
66 |
So far, the discussion has indicated not more than a shift of programs |
67 |
from / to /usr. This, IMO, should be controlled by a profile/use-flag |
68 |
setting. That is, gen_usr_ldscript should NOT go, but rather stay, and |
69 |
just do nothing if the user is following the GnomeOS vision. |
70 |
|
71 |
-- |
72 |
Fabian Groffen |
73 |
Gentoo on a different level |