Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]

[Michael Mol]

On Thu, Mar 22, 2012 at 5:13 PM, Walter Dnes <waltdnes@××××××××.org> wrote:
> 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.

No. In a system V scenario, you'd probably just symlink to the
genericized init script. In the systemd scenario, as I understand it,
you have a configuration file (distinct from a script), and you'd
include the path to the genericized init script there.

What I'm talking about is an implementation of the adapter pattern.
http://en.wikipedia.org/wiki/Adapter_pattern

If there are going to be competing init systems (and there will be),
and a service needs to be compatible with both (and there will be such
services), then that's going to be the most elegant solution.

>
>> 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)

Sure. And that's what I was arguing. Though by the sound of it,
there's stuffed in the openrc package which doesn't need to be there,
and a blog post flameeyes posted today suggests the systemd package is
intended to absorb the hardware database. (
http://blog.flameeyes.eu/2012/03/refreshing-a-4-years-old-problem )

>
>> 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.

And that's the way it should be.

>
>> 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.

See reference to the adapter pattern above.

Systemd has its merits in its capabilities. System V init has merits
in that it's far more portable. Open source software which operates as
a system service will need to support both.

There are, of course, things I loathe. I loathe the apparent mindset
behind systemd and behind udev, wherein all things belong as part of a
monolithic system. That runs counter to principles of modular design,
portability and even systemic stability in changing things. I loathe
the desire to lunge forward without working out a transition plan, or
even having the appearance of interest in one. And I loathe the
terrible PR.

-- 
:wq