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
Status: RESOLVED FIXED
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
URL:
Whiteboard:
Keywords:
: 560044 602846 618466 (view as bug list)
Depends on: init.d_functions.sh
Blocks:
  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: ---


Attachments

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 functions.sh" 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
profiles/base/packages:48:
# stopgap solution for functions.sh #373219
*sys-apps/openrc
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 :(

http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/packages?r1=1.65&r2=1.66
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)

Yes:
$ cat /etc/portage/profile/packages 
-*sys-apps/openrc
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)

Thanks!
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/functions.sh to /lib/gentoo/functions.sh, 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/functions.sh need to be changed to move over to another path, such as /lib/gentoo/functions.sh (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/functions.sh 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/functions.sh, and naturally can't find it when OpenRC is removed. Are you telling me that /etc/init.d/functions.sh 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/functions.sh 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
-*sys-apps/openrc
Comment 14 Dainius Masiliūnas 2016-03-23 17:04:13 UTC
(In reply to m.cassaniti@gmail.com 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 (startDM.sh 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):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ace3d16092a886de6d7eacc65f7a0d5593b95ac

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

    profiles: remove sys-apps/openrc from @system
    
    Closes: https://bugs.gentoo.org/511500

 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:
  default/linux/amd64/17.0/desktop/plasma/systemd
```

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.