Gentoo Archives: gentoo-user

From: Michael Mol <mikemol@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
Date: Thu, 22 Mar 2012 01:37:40
In Reply to: Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ] by Walter Dnes
1 On Wed, Mar 21, 2012 at 6:55 PM, Walter Dnes <waltdnes@××××××××.org> wrote:
2 > On Wed, Mar 21, 2012 at 12:02:32PM -0400, Michael Mol wrote
3 >
4 >> I said this before, but it sounds useful to try to reiterate:
5 >>
6 >> * It's probable that service-specific files should not be included in
7 >> the init system package.
8 >> * Service-specific init files should probably be part of the
9 >> distro-localized version of a service-providing package.
10 >>
11 >> This doesn't mean modifying binaries, this is part of bootstrapping a
12 >> service's environment. Call it "deferred installation stages", if you
13 >> like; things which need to be done for the service to be configured
14 >> and properly operate.
15 >
16 >  My point is that the startup, sanity-checking, and initialization code
17 > has to go *SOMEWHERE*.  Where do you propose moving it to?
19 Sure. But there's a difference between moving, e.g. sshd's first-time
20 code into the net-misc/openssh package and moving it into the sshd
21 binary itself.
23 I don't want to sound condescending, but I really don't know how much
24 of this is going to be generally known on this list, and I get the
25 impression that it's unclear...
27 (Also, I'm not an expert on this...)
29 The distribution of software, as I understand it, generally has three
30 groups of people who hold it:
32 1) Upstream. Generally, upstream will keep their software portable and
33 agnostic, so it can be installed in a variety of places. That's not a
34 requirement, but it's considered polite in the open-source world, and
35 fairly necessary if they want the software to be broadly used.
36 Upstream is expected to know their software well enough to keep it in
37 active development, or at least in current maintenance.
39 2) Packager. A packager adapts upstream's software so that it fits in
40 and plays nicely with the rest of the software in the system. The
41 packager is expected to have the required understanding of both the
42 software and the target distribution in order to accomplish this.
44 3) End user. The end user isn't typically expected to have a full
45 understanding of the software or the distribution. He'll run the
46 distribution's package manager to install the software, follow any
47 instructions given for configuration, and apply any domain expertise
48 he has to configure things to conform to site-local needs.
50 What we're talking about with systemd vs openrc, and things like ssh'd
51 first-time initialization is all within the realm of responsibility of
52 the packager. It's a shift in the way the distribution itself works.
53 We're not talking about a scenario where you shunt things upstream, so
54 the whole "your position would have rejected Linux" angle is a red
55 herring.
57 Now, let's look at what an init system does. For each service, it
58 spawns some process, checks a return code, declares either success or
59 failure, and may take some further action based on that success or
60 failure.
62 Why does that spawned process have to be sshd? Why can't it be some
63 shell script which does the one-time checks, and then launches sshd
64 itself? Why does that shell script need to be distributed as part of
65 the init system's package, and not part of the package associated with
66 the service?
68 Having the shell script be part of the package associated with the
69 service keeps bugs related to that script associated with that
70 package.
72 As far as compatibility between init systems is concerned, you can
73 symlink the init system's launch file (e.g. /etc/init.d/some_file) to
74 wherever this shell script is, or you can configure the init system
75 such that it knows where the shell script is.
77 At least, that's the way I see it. Any issue of compatibility between
78 the two can be addressed by the service's package manager, either by
79 adaption via that script, or by expressing an explicit dependency on
80 one init architecture or another.
82 --
83 :wq


Subject Author
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ] Walter Dnes <waltdnes@××××××××.org>