El jue, 21-04-2011 a las 15:52 -0500, William Hubbs escribió: > On Thu, Apr 21, 2011 at 10:03:42PM +0200, Pacho Ramos wrote: > > El jue, 21-04-2011 a las 14:30 -0500, William Hubbs escribió: > > > On Wed, Apr 20, 2011 at 08:20:32PM +0200, Pacho Ramos wrote: > > > > El mié, 20-04-2011 a las 22:02 +0400, Peter Volkov escribió: > > > > > В Срд, 20/04/2011 в 12:24 -0500, William Hubbs пишет: > > > > > > The author of the bug feels that the way to fix this is for us to > > > > > > put a > > > > > > check in openrc that makes it refuse to run services if it was not > > > > > > used > > > > > > in the boot process. > > > > > > > > > > This is good idea to have in any case since I remember my system went > > > > > crazy after I've tried to start some service inside chroot. > > > > > > > > > > > This may work; however, I do not feel that it addresses the root > > > > > > cause > > > > > > of the bug. I feel that the root cause is packages unconditionally > > > > > > installing udev rules which assume everyone uses openrc. > > > > > > > > > > I'd voted to have both implemented. > > > > > > > > > > > > > I would vote for the first one, I still don't like "openrc" USE flag > > > > approach much because: > > > > 1. Would need to rebuild some packages when switching between init > > > > systems. > > > > > > I don't think you can get away from this, no matter how you approach > > > it. The other approach I thought of is to include the udev pieces > > > directly in openrc and make it possible to build openrc with or without > > > udev integration. That will still mean you have to rebuild openrc though > > > if you want udev support. > > > > > > > With mgorny's approach looks like recompiling wouldn't be needed :-/ > > His approach doesn't stop udev from attempting to run the services; it > just makes openrc print an error message and abort each service we try > to run. > > With the integration into udev that we have right now, some of our udev > rules expect openrc to be usable. > > William >
Didn't know that, thanks again
signature.asc
Description: This is a digitally signed message part
