[gentoo-dev] rfc: openrc use flag

[gentoo-dev] rfc: openrc use flag

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

All,

This bug [1] brings up an issue that I would like thoughts about.

sys-fs/udev and net-wireless/bluez, among other packages, install udev
rules which assume that you are using openrc.

On systems where openrc is not used in the boot process, this causes
issues because openrc services are run by the udev rules even though
openrc did not boot the system.

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 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.

My proposal is to give these packages an "openrc" use flag which will
control whether or not openrc specific support will be installed. This
would be on by default, of course, since most of us use openrc.

The author of the bug is correct about the disadvantage of doing this --
if you want to switch on or off openrc support, this will require a
rebuild of the affected packages.

I feel that the advantage of this approach outweighs this disadvantage
because this approach allows the user to tell udev not to even attempt
to run openrc services, and this will lead to a more efficient system.

Any input would be appreciated.

William

[1] http://bugs.gentoo.org/show_bug.cgi?id=364159

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[Peter Volkov]

В Срд, 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.

-- 
Peter.

Re: [gentoo-dev] rfc: openrc use flag

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

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.
2. I remember (from "logrotate" USE flag case) that using an USE flag
for simply installing or not a file is not usually preferred :-/

Best regards

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
> В Срд, 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.

My concern about it though is prefix installs. If I implement something
like this, will it not break openrc on prefix systems?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[Michał Górny]

[-- Attachment #1.1: Type: text/plain, Size: 1220 bytes --]

On Wed, 20 Apr 2011 13:22:53 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
> > В Срд, 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.
> 
> My concern about it though is prefix installs. If I implement
> something like this, will it not break openrc on prefix systems?

I'm attaching the patch I suggested to fix the issue.

It is based on the assumption that in order to run cleanly, OpenRC
needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark all services
stopped). It assumes that the basic effect of a running OpenRC
is a determined runlevel stored in ${RC_SVCDIR}/softlevel file.

I tested that approach with clean OpenRC and systemd installs, and it
doesn't create any issues. I'd appreciate if someone with Prefix system
could test it as well.


-- 
Best regards,
Michał Górny

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-Add-a-check-for-softlevel-when-running-init.d-script.patch --]
[-- Type: text/x-patch, Size: 979 bytes --]

From ac70101ad50348fee636cea36cefcd473ee45690 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= <mgorny@gentoo.org>
Date: Wed, 20 Apr 2011 15:34:08 +0200
Subject: [PATCH] Add a check for softlevel when running init.d scripts.

${RC_SVCDIR}/softlevel should be a good file to check for before running
a OpenRC script. This should fix http://bugs.gentoo.org/show_bug.cgi?id=364159.
---
 src/rc/runscript.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/rc/runscript.c b/src/rc/runscript.c
index 0eca487..b7cc810 100644
--- a/src/rc/runscript.c
+++ b/src/rc/runscript.c
@@ -1112,6 +1112,11 @@ runscript(int argc, char **argv)
 		exit(EXIT_FAILURE);
 	}
 
+	if (!exists(RC_SVCDIR "/softlevel")) {
+		fprintf(stderr, "OpenRC is not running\n");
+		exit(EXIT_FAILURE);
+	}
+
 	if (stat(argv[1], &stbuf) != 0) {
 		fprintf(stderr, "runscript `%s': %s\n",
 		    argv[1], strerror(errno));
-- 
1.7.5.rc1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[Fabian Groffen]

On 20-04-2011 13:22:53 -0500, William Hubbs wrote:
> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
> > В Срд, 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.
> 
> My concern about it though is prefix installs. If I implement something
> like this, will it not break openrc on prefix systems?

does such thing exist?


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] rfc: openrc use flag

[Jeroen Roovers]

On Wed, 20 Apr 2011 22:02:41 +0400
Peter Volkov <pva@gentoo.org> wrote:

> В Срд, 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.

Why refuse? It could instead assume it needed to only start a service
in, say, a chroot, like ssh or apache2, without assuming anything else
needs to be done. If the service needed anything else, it could be
left to fail on its own terms.

> 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.

Basically, baselayout/openrc (baselayout-1 has the same problem) would
(try to) shut down your system because it thought something was
terribly wrong. That's bitten me as well when I still thought I could
test services inside a 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.

How should the udev rules be changed to match /any/ init system?


     jer

Re: [gentoo-dev] rfc: openrc use flag

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

On Thu, Apr 21, 2011 at 04:31:46AM +0200, Jeroen Roovers wrote:
> On Wed, 20 Apr 2011 22:02:41 +0400
> Peter Volkov <pva@gentoo.org> wrote:
> 
> > В Срд, 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.
> 
> Why refuse? It could instead assume it needed to only start a service
> in, say, a chroot, like ssh or apache2, without assuming anything else
> needs to be done. If the service needed anything else, it could be
> left to fail on its own terms.
 
 This might be possible; I would just change the message in the patch
 provided to something like,

"Warning, openrc did not boot this system, so you may get unpredictable results.\n"

> > 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.
> 
> Basically, baselayout/openrc (baselayout-1 has the same problem) would
> (try to) shut down your system because it thought something was
> terribly wrong. That's bitten me as well when I still thought I could
> test services inside a 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.
> 
> How should the udev rules be changed to match /any/ init system?

For an example of the problem, take a look on your system at
/lib/udev/rules.d/90-network.rules. This is part of openrc's hotplug
functionality. Basically it tries to run
/etc/init.d/net.$INTERFACE start when a network interface is added to
the system and rc_hotplug allows it.
 
In net-wireless/bluez, you will see similar integration between openrc
and udev. Once bluez is installed, /lib/udev/rules.d/70-bluetooth.rules
runs bluetooth.sh which tries to run a service in /etc/init.d.

To make things work with /any/ init system, the best way to go would be
to make it a practice not to run services from within udev rules or
external run scripts like net.sh and bluetooth.sh in /lib/udev.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: rfc: openrc use flag

[Duncan]

Michał Górny posted on Wed, 20 Apr 2011 20:33:27 +0200 as excerpted:

> On Wed, 20 Apr 2011 13:22:53 -0500 William Hubbs <williamh@gentoo.org>
> wrote:
> 
>> On Wed, Apr 20, 2011 at 10:02:41PM +0400, Peter Volkov wrote:
>> > В Срд, 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.
>> 
>> My concern about it though is prefix installs.
> 
> [The attached patch] is based on the assumption that in order to run
> cleanly, OpenRC needs to do some cleanup in ${RC_SVCDIR} (e.g. to mark
> all services stopped). It assumes that the basic effect of a running
> OpenRC is a determined runlevel stored in ${RC_SVCDIR}/softlevel file.
> 
> I tested that approach with clean OpenRC and systemd installs, and it
> doesn't create any issues. I'd appreciate if someone with Prefix system
> could test it as well.

> http://bugs.gentoo.org/show_bug.cgi?id=364159.

The patch seems reasonable, but I can't but think that there's likely 
corner-cases that may be unknown ATM that could complicate things.  If we 
establish a slightly broader base now, it can be reasonably expanded in 
the future.

What about handling this much the same as subsystem-type auto-detection 
was ultimately handled, but controlling how much of openrc should run:

1) Auto: (like rc_sys being commented out).  This would do the auto-detect 
thing using something like the suggested softlevel file detection patch.

2) On:  Openrc is locked ON, and will try to handle everything.  This 
could be the default (much like rc_sys="").

3) Off: Openrc is locked OFF, and will immediately terminate as soon as it 
loads the config far enough to see that it is OFF, if anything attempts to 
run it.

4) Later? Nodep:  (Target stable-next?)  If the setting is "nodep", openrc 
should assume all deps are met and simply run the script it is asked to 
run, only.

5) Optionally, service.allowed: (Target bluesky?)  Another setting could 
list specific services that openrc should be allowed to run.  If 
service.allowed isn't empty/unset, anything not listed would not be run.  
Nodep mode would be altered slightly by this, in that any listed service 
could be depended normally, while anything not listed would be assumed to 
be dependency-met.  Normal (auto/on) mode would work in the reverse for 
anything not listed.  Since openrc isn't allowed to touch those services 
but is operating in normal dependency mode, to openrc they'd not exist and 
therefore block the start of any depending services as well.

6) Optionally, service.provided: To go along with #5, for openrc in normal 
mode, it could borrow the "package.provided" concept from portage, making 
it "service.provided".  For normal mode, services listed in this third 
setting, but ONLY these services, would be assumed to be met much as if 
openrc was operating in nodeps mode.  Services not in this list would be 
treated as above.  (This would allow openrc to nodep on services in 
service.provided, while failing OTHER deps not found in service.allowed, 
if service.allowed isn't empty/unset.

7) Optionally, service.blacklisted.  This would be the negative version of 
#5.  Presumably, if both service.allowed AND service.blacklisted are set 
and non-empty, one would take precedence and the other would be ignored 
(with documentation as to which was which).

Obviously #5-7 are wish-list, not really appropriate for our current 
target-stable.  However, *if* they were thought sufficiently useful to 
code up, these features could appear with a later version.

At least #1-3 should be quite easy to code and appropriate for stable, 
since the config concept and implementation has already been tested to 
some degree with the current but quite new subsystem-type implementation.

#4 falls in the middle.  I threw it in based on jer's suggestion, which 
I'd like to see even if #5-7 aren't implemented, but it's a big enough 
feature-add that it really should have additional testing. As such I don't 
see it for current-stable-target, but perhaps stable-next?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] rfc: openrc use flag

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

On Wed, Apr 20, 2011 at 11:34:59PM -0500, William Hubbs wrote:
> On Thu, Apr 21, 2011 at 04:31:46AM +0200, Jeroen Roovers wrote:
> > How should the udev rules be changed to match /any/ init system?
> 
> For an example of the problem, take a look on your system at
> /lib/udev/rules.d/90-network.rules. This is part of openrc's hotplug
> functionality. Basically it tries to run
> /etc/init.d/net.$INTERFACE start when a network interface is added to
> the system and rc_hotplug allows it.
>  
> In net-wireless/bluez, you will see similar integration between openrc
> and udev. Once bluez is installed, /lib/udev/rules.d/70-bluetooth.rules
> runs bluetooth.sh which tries to run a service in /etc/init.d.
> 
> To make things work with /any/ init system, the best way to go would be
> to make it a practice not to run services from within udev rules or
> external run scripts like net.sh and bluetooth.sh in /lib/udev.

Another option for this would be to include this level of udev
integration in the openrc package itself instead of spreading it through
the other packages.

If I do that, when you install openrc, you would optionally get those
pieces that integrate it with udev instead of those pieces coming from
the individual packages.

Comments?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

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.

> 2. I remember (from "logrotate" USE flag case) that using an USE flag
> for simply installing or not a file is not usually preferred :-/

In the logrotate use flag case, that decision was made because a user
can use INSTALL_MASK="/etc/logrotate.d" in make.conf to block those
files. But that argument definitely does not apply here. If the user
doesn't want this support what should he set INSTALL_MASK to?
 
 William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]

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 :-/


> > 2. I remember (from "logrotate" USE flag case) that using an USE flag
> > for simply installing or not a file is not usually preferred :-/
> 
> In the logrotate use flag case, that decision was made because a user
> can use INSTALL_MASK="/etc/logrotate.d" in make.conf to block those
> files. But that argument definitely does not apply here. If the user
> doesn't want this support what should he set INSTALL_MASK to?
>  

That's true, thanks for the explanation :)

>  William
> 



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[Peter Volkov]

В Чтв, 21/04/2011 в 14:30 -0500, William Hubbs пишет:
> On Wed, Apr 20, 2011 at 08:20:32PM +0200, Pacho Ramos wrote:
> > 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.

Do we allow installation of two init systems side by side? If yes, then
eselect module can be used to change services that will be stated by
udev.

-- 
Peter.

Re: [gentoo-dev] rfc: openrc use flag

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On Fri, 22 Apr 2011 12:26:36 +0400
Peter Volkov <pva@gentoo.org> wrote:

> В Чтв, 21/04/2011 в 14:30 -0500, William Hubbs пишет:
> > On Wed, Apr 20, 2011 at 08:20:32PM +0200, Pacho Ramos wrote:
> > > 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.
> 
> Do we allow installation of two init systems side by side? If yes,
> then eselect module can be used to change services that will be
> stated by udev.

I don't see a reason to engage another tool in there. RC is supposed to
handle it itself, it should better know whether it is being used,
shouldn't it?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: openrc use flag

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

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 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]