1 |
On Wed, Mar 21, 2012 at 2:12 PM, Zac Medico <zmedico@g.o> wrote: |
2 |
> On 03/20/2012 04:23 AM, Tony "Chainsaw" Vroon wrote: |
3 |
> |
4 |
>> If it is, newer udev can not be stabled and alternatives should be |
5 |
>> investigated. |
6 |
> |
7 |
> A possible compromise would be to use pkg_pretend to check if /usr is a |
8 |
> mount point, and die if the user hasn't set a variable or a USE flag to |
9 |
> indicate awareness that /usr must be mounted early. |
10 |
|
11 |
I'm avoiding commenting redundant with the whole previous email chain, |
12 |
but I don't really see this as anything other than a mitigation during |
13 |
some temporary migration period. That is, unless you want to keep |
14 |
udev-171 in the tree for the next 15 years or until the default is |
15 |
some other replacement without this limitation. |
16 |
|
17 |
Unless somebody is actually willing to maintain a robust alternative I |
18 |
don't really see that as a real option. If upstream moves in one |
19 |
direction, and nobody is willing to maintain things in a different |
20 |
state, then you just end up with a system package that nobody wants to |
21 |
use, and something in an overlay that everybody uses instead that is |
22 |
beyond these debates. You can't effectively mandate that people |
23 |
maintain something in a volunteer organization, unless the effort |
24 |
involved is very minor. |
25 |
|
26 |
The Council can of course lend moral support to a particular |
27 |
direction, but Gentoo will only get there if somebody writes the code. |
28 |
Right now I don't see anybody maintaining a robust /usr-less udev |
29 |
fork yet. If one existed the Council could easily make one vs the |
30 |
other default, or ask to have it in the handbook, etc. |
31 |
|
32 |
> |
33 |
>> If it isn't, a lot of documentation will have to be |
34 |
>> updated. (And an alternative should likely still be provided) |
35 |
|
36 |
I'd say that quite a bit of documentation needs to be updated before |
37 |
udev is stabilized in any case. |
38 |
|
39 |
Rich |