Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03
Date: Wed, 21 Mar 2012 21:03:21
Message-Id: CAGfcS_mc=kdpGPfYg=cqgs+S8tbM2tgZEnzcD5f9noR2SS7b3g@mail.gmail.com
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting 2012-04-03 by Zac Medico
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