1 |
On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote |
2 |
|
3 |
> What we're talking about with systemd vs openrc, and things like ssh'd |
4 |
> first-time initialization is all within the realm of responsibility of |
5 |
> the packager. It's a shift in the way the distribution itself works. |
6 |
> We're not talking about a scenario where you shunt things upstream, so |
7 |
> the whole "your position would have rejected Linux" angle is a red |
8 |
> herring. |
9 |
|
10 |
This is a frustrating game of whack-a-mole. Person A comes up with a |
11 |
position, I rebut it, and then person B comes up with a different |
12 |
position, and I have to rebut it.. There have been people in this |
13 |
thread who have said that the program best knows what it needs, and |
14 |
should handle its own initialization. That was what I was replying to. |
15 |
I'll reply to your position now. |
16 |
|
17 |
> Why does that spawned process have to be sshd? Why can't it be some |
18 |
> shell script which does the one-time checks, and then launches sshd |
19 |
> itself? |
20 |
|
21 |
So instead of the initscript doing the checking+setup and launching |
22 |
the service, it launches a a second script... which does the |
23 |
checking+setup and launches the service <FACEPALM>. See my post with |
24 |
the joke of digging a second hole to dump the dirt from the first hole |
25 |
into. Instead of one script, we now have two scripts. This is *NOT* |
26 |
simplification. |
27 |
|
28 |
> Why does that shell script need to be distributed as part of the |
29 |
> init system's package, and not part of the package associated with |
30 |
> the service? |
31 |
|
32 |
I don't understand what you're arguing here. *THE INITSCRIPT IS OWNED |
33 |
BY THE SERVICE PACKAGE*, not by the init package. E.g. net-misc/openssh, |
34 |
not sys-apps/openrc. |
35 |
|
36 |
waltdnes@d530 ~ $ equery b /etc/init.d/sshd |
37 |
* Searching for /etc/init.d/sshd ... |
38 |
net-misc/openssh-5.8_p1-r1 (/etc/init.d/sshd) |
39 |
|
40 |
> Having the shell script be part of the package associated with the |
41 |
> service keeps bugs related to that script associated with that |
42 |
> package. |
43 |
|
44 |
That's the way it is right now. See above. |
45 |
|
46 |
> At least, that's the way I see it. Any issue of compatibility between |
47 |
> the two can be addressed by the service's package manager, either by |
48 |
> adaption via that script, or by expressing an explicit dependency on |
49 |
> one init architecture or another. |
50 |
|
51 |
My point in this whole argument is that there is some checking and |
52 |
setup that has to be done before launch. Therefore shuffling off some |
53 |
or all of the shellscript code to another script is a pointless "shell |
54 |
game" (sorry) that adds no value. |
55 |
|
56 |
-- |
57 |
Walter Dnes <waltdnes@××××××××.org> |