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