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

[Michael Mol <mikemol@gmail.com>]

On Wed, Mar 21, 2012 at 6:55 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Wed, Mar 21, 2012 at 12:02:32PM -0400, Michael Mol wrote
>
>> I said this before, but it sounds useful to try to reiterate:
>>
>> * It's probable that service-specific files should not be included in
>> the init system package.
>> * Service-specific init files should probably be part of the
>> distro-localized version of a service-providing package.
>>
>> This doesn't mean modifying binaries, this is part of bootstrapping a
>> service's environment. Call it "deferred installation stages", if you
>> like; things which need to be done for the service to be configured
>> and properly operate.
>
>  My point is that the startup, sanity-checking, and initialization code
> has to go *SOMEWHERE*.  Where do you propose moving it to?

Sure. But there's a difference between moving, e.g. sshd's first-time
code into the net-misc/openssh package and moving it into the sshd
binary itself.

I don't want to sound condescending, but I really don't know how much
of this is going to be generally known on this list, and I get the
impression that it's unclear...

(Also, I'm not an expert on this...)

The distribution of software, as I understand it, generally has three
groups of people who hold it:

1) Upstream. Generally, upstream will keep their software portable and
agnostic, so it can be installed in a variety of places. That's not a
requirement, but it's considered polite in the open-source world, and
fairly necessary if they want the software to be broadly used.
Upstream is expected to know their software well enough to keep it in
active development, or at least in current maintenance.

2) Packager. A packager adapts upstream's software so that it fits in
and plays nicely with the rest of the software in the system. The
packager is expected to have the required understanding of both the
software and the target distribution in order to accomplish this.

3) End user. The end user isn't typically expected to have a full
understanding of the software or the distribution. He'll run the
distribution's package manager to install the software, follow any
instructions given for configuration, and apply any domain expertise
he has to configure things to conform to site-local needs.

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.

Now, let's look at what an init system does. For each service, it
spawns some process, checks a return code, declares either success or
failure, and may take some further action based on that success or
failure.

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

Having the shell script be part of the package associated with the
service keeps bugs related to that script associated with that
package.

As far as compatibility between init systems is concerned, you can
symlink  the init system's launch file (e.g. /etc/init.d/some_file) to
wherever this shell script is, or you can configure the init system
such that it knows where the shell script is.

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.

-- 
:wq