Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 511500 - Remove *sys-apps/openrc from base system profile
Summary: Remove *sys-apps/openrc from base system profile
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal with 5 votes (vote)
Assignee: Gentoo's Team for Core System packages
: 560044 602846 618466 (view as bug list)
Depends on:
  Show dependency tree
Reported: 2014-05-25 23:59 UTC by thomasg
Modified: 2022-07-30 13:06 UTC (History)
28 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description thomasg 2014-05-25 23:59:18 UTC
The base profile includes a system level dependency for sys-apps/openrc, which isn't needed on systemd systems.
According to the profile comment in the packages file, this is a "stopgap solution for" as documented in #373219
Meanwhile this bug has been fixed, so this can (and should be) removed.

Reproducible: Always
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2014-05-26 00:07:34 UTC
# stopgap solution for #373219
Comment 2 Samuli Suominen (RETIRED) gentoo-dev 2014-05-26 13:26:19 UTC
(In reply to thomasg from comment #0)
> Meanwhile this bug has been fixed, so this can (and should be) removed.

nope :(
Comment 3 Dennis Schridde 2015-06-21 22:50:49 UTC
Is it possible to manually override profiles/base/packages? I.e. remove a package from @system locally?
Comment 4 Pavel Volkov 2015-06-21 22:53:44 UTC
(In reply to Dennis Schridde from comment #3)

$ cat /etc/portage/profile/packages 
Comment 5 Dennis Schridde 2015-06-22 06:29:44 UTC
(In reply to Pavel Volkov from comment #4)
> (In reply to Dennis Schridde from comment #3)

Comment 6 Brian Evans (RETIRED) gentoo-dev 2015-09-09 14:24:52 UTC
*** Bug 560044 has been marked as a duplicate of this bug. ***
Comment 7 MCassaniti 2016-02-18 05:36:38 UTC
Given the last comment, is it worthwhile instead to add '-*sys-apps/openrc' into the systemd profile package list (i.e.: profiles/targets/systemd) ? I can confirm that simply adding this file resolves the issue at present.

Since OpenRC is the default service-manager, I think it's overkill to remove it from the base profile. Removing it for the systemd target is however a better move.
Comment 8 MCassaniti 2016-02-23 00:45:55 UTC
I'd like to expand my previous statements.

1. It should be possible to add '-*sys-apps/openrc' to /etc/portage/profiles/packages, and to system profiles like /usr/portage/profiles/targets/systemd/packages
2. sys-apps/gentoo-functions needs a new USE flag to create a symlink from /etc/init.d/ to /lib/gentoo/, which could simply be the symlink USE flag.
3. If step 2 can't or shouldn't be done, then all scripts relying on /etc/init.d/ need to be changed to move over to another path, such as /lib/gentoo/ (this is what the 2yr old bug 504116 is for).

I can't comment on how sys-apps/gentoo-functions works on non-Linux platforms and if that causes issues with this sort of change.
Comment 9 Pavel Volkov 2016-02-23 07:53:11 UTC
No need for USE flag, we are just one blocker bug away (dev-java/java-config-wrapper) from getting rid of /etc/init.d/ path.
Comment 10 Pavel Volkov 2016-02-23 07:57:44 UTC
Oh wait, java-config-wrapper is fixed, too. Just not marked fixed.
It's almost time to act on this one.
Comment 11 MCassaniti 2016-02-25 00:42:59 UTC
My reason for looking into this was gcc-config and python-updater, both of which go looking for /etc/init.d/, and naturally can't find it when OpenRC is removed. Are you telling me that /etc/init.d/ itself is no longer required, or that the contents of the file should now be provided by gentoo-functions and not OpenRC?
Comment 12 Pavel Volkov 2016-02-25 05:58:14 UTC
Only /lib/gentoo/ is required, provided by gentoo-functions.
gcc-config and python-updater are both fixed, see bug #504118 and bug #504130.
Comment 13 MCassaniti 2016-02-29 02:17:17 UTC
Should the suggested changes for the systemd target get added at this point, and the Gentoo systemd documentation updated to explain removing OpenRC, then adding '-*sys-apps/openrc' to /etc/portage/profiles/packages?

/usr/portage/profiles/targets/systemd/packages should now contain:
# OpenRC not required for systemd target
Comment 14 Dainius Masiliūnas 2016-03-23 17:04:13 UTC
(In reply to from comment #7)
> Given the last comment, is it worthwhile instead to add '-*sys-apps/openrc'
> into the systemd profile package list (i.e.: profiles/targets/systemd) ? I
> can confirm that simply adding this file resolves the issue at present.

Keep in mind that systemd subprofiles are available only for select profiles. There's no hardened/systemd nor x32/systemd profiles, for instance. Profiles ought to be combinable, but it would require an overhaul of the profile system to achieve that...
Comment 15 MCassaniti 2016-03-24 00:06:38 UTC
I'd like to see that the systemd target is edited, even though it isn't a sub-profile for other relevant profiles. I've also edited the systemd documentation on the Gentoo Wiki to note that adding the *-sys-apps/openrc to /etc/portage/profiles/packages is required if a systemd profile is not available.
Comment 16 Dainius Masiliūnas 2016-09-03 17:56:33 UTC
Yes, as a workaround right now I made symlinks from the systemd target to /etc/portage/profile/package.use.mask and /etc/portage/package.mask. Having a "packages" file in the systemd profile would at least allow using a symlink for that too, so that it updates in sync with the systemd target.
Comment 17 Brian Evans (RETIRED) gentoo-dev 2016-12-16 17:30:49 UTC
*** Bug 602846 has been marked as a duplicate of this bug. ***
Comment 18 d9867eb 2017-05-14 23:04:59 UTC
*** Bug 618466 has been marked as a duplicate of this bug. ***
Comment 19 Ben Kohler gentoo-dev 2017-12-10 16:30:16 UTC
I propose that we move forward with removing openrc from the profile, the 2 outstanding bugs ( and netqmail) are not important enough to hold this back.

If anyone feels like fixing those, they can, but they are not important.
Comment 20 Ben Kohler gentoo-dev 2017-12-11 14:36:09 UTC
FYI I have done test builds of new stage3s and this removal should not affect them in any way.
Comment 21 Larry the Git Cow gentoo-dev 2017-12-11 17:21:29 UTC
The bug has been closed via the following commit(s):

commit 8ace3d16092a886de6d7eacc65f7a0d5593b95ac
Author:     Mike Gilbert <>
AuthorDate: 2017-12-11 17:20:42 +0000
Commit:     Mike Gilbert <>
CommitDate: 2017-12-11 17:20:42 +0000

    profiles: remove sys-apps/openrc from @system

 profiles/base/packages | 2 --
 1 file changed, 2 deletions(-)
Comment 22 Erik Quaeghebeur 2017-12-11 20:20:42 UTC
When depcleaning, one still gets a scary warning:

# emerge -cqa
net-misc/netifrc: 0.5.1 none none 

!!! 'sys-apps/openrc' (virtual/service-manager) is part of your system profile.
!!! Unmerging it may be damaging to your system.

sys-apps/openrc: 0.34.11 none none 
sys-apps/sysvinit: 2.88-r9 none none 
virtual/tmpfiles: 0 none none

I have a systemd profile:

# eselect profile show
Current /etc/portage/make.profile symlink:

Perhaps something can be done to avoid this warning on systemd profiles.
Comment 23 Ben Kohler gentoo-dev 2017-12-11 20:23:11 UTC
See bug 375115 for discussion on that, I don't really know what can be done from the profile side to work around this
Comment 24 Tim 2018-01-06 00:09:58 UTC
I was quite surprised when I discovered that my raspberry pi had no /sbin/init today - it seems that in january of 2017 I installed daemontools, which satisfies the virtual/service-manager dependency, and allowed emerge to depclean openrc when I wasn't paying attention.

Now arguably, I should pay better attention to what the machine is doing, and that's on me - but I do not think that it makes sense for daemontools to replace an init system if it doesn't have /sbin/init, and it seems dangerous for the virtual to be satisfied by it.
Comment 25 Hector Martin 2018-08-16 10:01:46 UTC
Um, yeah, this is no fun. If you have daemontools installed, depclean will happily go and try to remove openrc.

Is a pure-daemontools Gentoo system even remotely supported? If not, then this ought to be changed so that just having daemontools installed isn't enough to satisfy the virtual/service-manager dep for @system. openrc || systemd is fine, but having minor service managers that also happen to be deps for other packages (daemontoools got pulled in by djbdns) satisfy the default @system requirement is just a recipe for broken systems.