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.
# stopgap solution for functions.sh #373219
(In reply to thomasg from comment #0)
> Meanwhile this bug has been fixed, so this can (and should be) removed.
Is it possible to manually override profiles/base/packages? I.e. remove a package from @system locally?
(In reply to Dennis Schridde from comment #3)
$ cat /etc/portage/profile/packages
(In reply to Pavel Volkov from comment #4)
> (In reply to Dennis Schridde from comment #3)
*** Bug 560044 has been marked as a duplicate of this bug. ***
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.
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.
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.
Oh wait, java-config-wrapper is fixed, too. Just not marked fixed.
It's almost time to act on this one.
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?
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.
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
(In reply to email@example.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...
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.
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.
*** Bug 602846 has been marked as a duplicate of this bug. ***
*** Bug 618466 has been marked as a duplicate of this bug. ***
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.
FYI I have done test builds of new stage3s and this removal should not affect them in any way.
The bug has been closed via the following commit(s):
Author: Mike Gilbert <firstname.lastname@example.org>
AuthorDate: 2017-12-11 17:20:42 +0000
Commit: Mike Gilbert <email@example.com>
CommitDate: 2017-12-11 17:20:42 +0000
profiles: remove sys-apps/openrc from @system
profiles/base/packages | 2 --
1 file changed, 2 deletions(-)
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.
See bug 375115 for discussion on that, I don't really know what can be done from the profile side to work around this
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.
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.