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 |