Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] rfc: making sysvinit optional
Date: Thu, 11 Jul 2019 17:38:37
Message-Id: CAGfcS_nn+iZoF8TZXqmKyLYmfWaUHx=V4XxXapxg8bQ-umiUhQ@mail.gmail.com
In Reply to: Re: [gentoo-dev] rfc: making sysvinit optional by William Hubbs
1 On Thu, Jul 11, 2019 at 1:22 PM William Hubbs <williamh@g.o> wrote:
2 >
3 > On Thu, Jul 11, 2019 at 12:46:02PM -0400, Rich Freeman wrote:
4 > > On Thu, Jul 11, 2019 at 11:56 AM William Hubbs <williamh@g.o> wrote:
5 > > >
6 > > > On Thu, Jul 11, 2019 at 09:42:02AM -0400, Rich Freeman wrote:
7 > >
8 > > If somebody just installs openrc their expectation is going to be that
9 > > they get sysvinit or your substitute that actually works with openrc
10 > > out of the box. They're not going to want to have neither installed
11 > > simply because they have runit or systemd already installed. If
12 > > somebody is migrating from systemd to openrc that is exactly the
13 > > situation they would be in.
14 >
15 > And this would be handled by virtual/init and virtual/service-manager...
16 >
17 > If you are migrating, you would definitely want to be careful with
18 > --depclean until you knew exactly what you wanted to remove or make sure
19 > everything is in your world file that you don't want removed.
20 >
21
22 What value is virtual/init adding though? You don't have to be
23 careful with migrating if you don't use it. You get no benefit from
24 using the virtual instead of just depending directly on sysvinit,
25 because that is the only package in the virtual that provides a
26 reasonable init implementation for openrc to use.
27
28 Yes, we can add that extra layer and then half the time it doesn't do
29 anything and the other half the time it automatically does what the
30 user doesn't want it to do, and users can work around it. What it
31 won't ever do is make it easier to do what the user actually wants to
32 do.
33
34 If you do create a virtual/init then I'd just limit it to stuff that
35 provides a generic sysvinit implementation that will easily work with
36 any other service manager. I'd argue that is sysvinit, and maybe
37 busybox[make-symlinks]. Maybe your openrc init implementation does,
38 but I haven't looked at it. The rest simply don't provide an init
39 that is designed to be used with an arbitrary service manager.
40
41 Maybe to look at it another way: is this actually fixing a problem
42 that anybody is concerned about? It just seems like it is giving
43 portage freedom to shoot the user in the foot, for little real gain.
44
45 --
46 Rich