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