| View previous topic :: View next topic |
| Author |
Message |
chrroessner
Apprentice
Joined: 02 Dec 2003
Posts: 156
Location: Germany
|
 Posted: Wed Jul 02, 2014 12:47 pm Post subject: systemd running, can I remove openrc? |
 |
|
Hi,
I started diving into systemd and therefor have switched one server from openrc to systemd.
Now that everthing is working perfectly, I ask interested if I can safely remove openrc?
Thanks in advance |
|
| Back to top |
|
 |
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Jul 02, 2014 1:56 pm Post subject: |
|
|
This has been discussed before. I believe that there is one particular script (network-related?) contained in openrc that is still required on a systemd system. FWIU that script is getting split into its own package, separate from OpenRC. When that happens you will be able to remove OpenRC from a systemd system, but not until then. I have no idea what that status on this move is.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3133
|
| Posted: Wed Jul 02, 2014 6:10 pm Post subject: |
|
|
Netifrc was separated from openrc several months ago. Also, you never actually NEEDED this script to set network. It's a matter of wants and convenience. You could have written simple (2 lines? 3 in case of wifi?) script that would do the same job. The huge size is a price of portability and flexibility. Also, dhcpcd can be daemonized and work as a service too. You can use NetworkManager. Or perhaps something else I don't even know about, but it does the same job.
No, if you have systemd, you don't need openrc anymore. Until something breaks, of course, and you find an oversized paperclip where you expected your computer to be  |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Jul 02, 2014 6:29 pm Post subject: |
|
|
It wasn't a network related script, that was needed, it was one of the rc shell scripts, maybe functions.sh, I don't remember
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
sera
Retired Dev
Joined: 29 Feb 2008
Posts: 1017
Location: CET
|
| Posted: Wed Jul 02, 2014 8:26 pm Post subject: |
|
|
| sys-apps/gentoo-functions is what was split out to allow openrc free systems. It's not in stable yet. |
|
| Back to top |
|
|
potuz
Guru
Joined: 30 Jan 2010
Posts: 378
|
| Posted: Sun Nov 16, 2014 1:14 am Post subject: |
|
|
| sera wrote: | | sys-apps/gentoo-functions is what was split out to allow openrc free systems. It's not in stable yet. |
This is stable now and still an emerge --depclean does not get rid of openrc. I still get the funny:
| Code: |
$ equery depends netifrc
* These packages depend on netifrc:
sys-apps/openrc-0.12.4 (netifrc ? net-misc/netifrc)
$ equery depends openrc
* These packages depend on openrc:
net-misc/netifrc-0.2.2 (>=sys-apps/openrc-0.12)
virtual/service-manager-0 (!prefix ? sys-apps/openrc)
$
|
|
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Sun Nov 16, 2014 2:08 am Post subject: |
|
|
That looks like, you need to check your USE flags on openrc...
if you set | Code: | | sys-apps/openrc -netifrc |
and recompile openrc; netifrc becomes unused and can be depcleaned away. Then you can depclean openrc.
Alternatively, you can always just do | Code: | | emerge --depclean openrc netifrc |
and it will remove both. May want to ensure the prefix use flag is set for virtual/service-manager so that doesn't depend on openrc either. |
|
| Back to top |
|
|
potuz
Guru
Joined: 30 Jan 2010
Posts: 378
|
| Posted: Sun Nov 16, 2014 4:34 pm Post subject: |
|
|
| ct85711 wrote: | | May want to ensure the prefix use flag is set for virtual/service-manager so that doesn't depend on openrc either. |
Both openrc and netifrc should be removed by --depclean when no longer needed as both are not in @world. Also, regarding the prefix USE flag, something that I don't understand is:
| Code: |
$ USE="prefix" emerge -pv virtual/service-manager
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] virtual/service-manager-0 USE="(-prefix)" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
$
|
|
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Sun Nov 16, 2014 8:43 pm Post subject: |
|
|
| That was my fault with the service-manager, as I didn't look to see what the virtual/service-manager is doing directly. It's there to make sure your using some kind of service manager, and can ignore it. If it causes any troubles when you depclean netifrc openrc, then add that virtual in with the mix, and portage will reinstall it if it's needed using systemd that is already installed. |
|
| Back to top |
|
|
potuz
Guru
Joined: 30 Jan 2010
Posts: 378
|
| Posted: Sun Nov 16, 2014 8:56 pm Post subject: |
|
|
A depclean will not remove netifrc and openrc as they are needed by virtual/service-manager. I can unmerge them of course, but
my point is that by the example of
| Code: | | $ USE="prefix" emerge -pv virtual/service-manager |
it seems that if I do remove those guys they'll get pulled in the next world update. |
|
| Back to top |
|
|
gaireg
n00b
Joined: 19 Nov 2014
Posts: 1
|
| Posted: Wed Nov 19, 2014 12:40 pm Post subject: |
|
|
| potuz wrote: | A depclean will not remove netifrc and openrc as they are needed by virtual/service-manager. I can unmerge them of course, but
my point is that by the example of
| Code: | | $ USE="prefix" emerge -pv virtual/service-manager |
it seems that if I do remove those guys they'll get pulled in the next world update. |
openrc is part of the @system set which is basically defined in /usr/portage/profiles/base/packages
use to find out which packages belong to your profile @system set, so openrc will be merged next time you start an @world update, because @system belongs to @world.
I tried to override the base/packages but with no success, the same with masking.
_________________
Mit freundlichen Grüßen / With kind Regards
Randolph Maaßen |
|
| Back to top |
|
|
potuz
Guru
Joined: 30 Jan 2010
Posts: 378
|
| Posted: Wed Nov 19, 2014 12:53 pm Post subject: |
|
|
| gaireg wrote: |
openrc is part of the @system set which is basically defined in /usr/portage/profiles/base/packages
|
Ahh thanks, that's the actual reason. I didn't know it was in @system. Is there any reason to keep openrc in system instead of virtual/service-manager? that last one in principal could be satisfied by systemd and we could get rid of having two init systems. |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Wed Nov 19, 2014 12:58 pm Post subject: |
|
|
| gaireg wrote: | | I tried to override the base/packages but with no success, the same with masking. |
Try | Code: | package.provided
A list of packages (one per line) that portage should assume have been provided. Useful for porting to non-Linux systems. Basi‐
cally, it's a list that replaces the emerge --inject syntax.
For example, if you manage your own copy of a 2.6 kernel, then you can tell portage that 'sys-kernel/development-sources-2.6.7'
is already taken care of and it should get off your back about it.
Portage will not attempt to update a package that is listed here unless another package explicitly requires a version that is
newer than what has been listed. Dependencies that are satisfied by package.provided entries may cause installed packages satis‐
fying equivalent dependencies to be removed by emerge(1) --depclean actions (see the ACTIONS section of the emerge(1) man page
for more information).
Virtual packages (virtual/*) should not be specified in package.provided, since virtual packages themselves do not provide any
files, and package.provided is intended to represent packages that do provide files. Depending on the type of virtual, it may be
necessary to add an entry to the virtuals file and/or add a package that satisfies a virtual to package.provided.
Format:
- comments begin with # (no inline comments)
- one DEPEND atom per line
- relational operators are not allowed
- must include a version
Example:
# you take care of the kernel
sys-kernel/development-sources-2.6.7
# you installed your own special copy of QT
x11-libs/qt-3.3.0
# you have modular X but packages want monolithic
x11-base/xorg-x11-6.8 |
|
|
| Back to top |
|
|
imesg
Guru
Joined: 12 Jul 2002
Posts: 445
|
| Posted: Tue Nov 25, 2014 4:02 pm Post subject: |
|
|
Got rid of openrc and service-manager, as per this thread, and all things seemed to work ok.
However just did an emerge -u world which caused openrc and service-manager to be pulled in.
Looks like emerge -u world gets a new /usr/portage/profile/base/packages.
What gives?
Thanks any help. |
|
| Back to top |
|
|
okias
n00b
Joined: 03 Jul 2007
Posts: 17
Location: Czech Republic
|
| Posted: Thu Jun 29, 2017 3:28 pm Post subject: |
|
|
| same issue |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Thu Jun 29, 2017 7:19 pm Post subject: |
|
|
Service-manager is only a virtual, so does not install any files...
| Code: | RDEPEND="
prefix? ( >=sys-apps/baselayout-prefix-2.2 )
!prefix? (
|| (
sys-apps/openrc
kernel_linux? ( || (
sys-apps/systemd
sys-process/runit
virtual/daemontools
) ) ) )" |
In short, the virtual/service-manager is more of making sure you either have openrc (default), systemd, runit or virtual/daemontools installed...
Assuming you have systemd installed, you may want to try masking openrc; so have this package go onto the next package, systemd... |
|
| Back to top |
|
|
potuz
Guru
Joined: 30 Jan 2010
Posts: 378
|
| Posted: Thu Jun 29, 2017 8:14 pm Post subject: |
|
|
| ct85711 wrote: | Service-manager is only a virtual, so does not install any files...
| Code: | RDEPEND="
prefix? ( >=sys-apps/baselayout-prefix-2.2 )
!prefix? (
|| (
sys-apps/openrc
kernel_linux? ( || (
sys-apps/systemd
sys-process/runit
virtual/daemontools
) ) ) )" |
In short, the virtual/service-manager is more of making sure you either have openrc (default), systemd, runit or virtual/daemontools installed...
Assuming you have systemd installed, you may want to try masking openrc; so have this package go onto the next package, systemd... |
As mentioned above, openrc is part of system and you cannot avoid installing it by masking. The final culprit for this problem is https://bugs.gentoo.org/show_bug.cgi?id=373219.
| Code: | $ cat /usr/portage/profiles/base/packages
# Copyright 1999-2014 Gentoo Foundation.
# Distributed under the terms of the GNU General Public License, v2
# Gentoo Base Profile
......
# stopgap solution for functions.sh #373219 and #504116
*sys-apps/openrc
.....
|
See both mentioned bugs.
Also
| Code: |
# cat /etc/portage/package.mask/monolithic
sys-apps/openrc
# emerge -pvu world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N #] sys-apps/openrc-0.27.2::gentoo USE="ncurses netifrc pam unicode -audit -debug -newnet (-prefix) (-selinux) -static-libs" 0 KiB
[ebuild N ] net-misc/netifrc-0.5.1::gentoo 77 KiB
Total: 2 packages (2 new), Size of downloads: 77 KiB
The following mask changes are necessary to proceed:
(see "package.unmask" in the portage(5) man page for more details)
# required by net-misc/netifrc-0.5.1::gentoo
# /etc/portage/package.mask/monolithic:
=sys-apps/openrc-0.27.2
|
|
|
| Back to top |
|
|
Gentoo64
n00b
Joined: 21 Oct 2011
Posts: 52
Location: ::
|
| Posted: Mon Jul 03, 2017 9:10 pm Post subject: |
|
|
I put:
-*sys-apps/openrc
in /etc/portage/profile/packages
works. |
|
| Back to top |
|
|
|
Other Things Gentoo
