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? |
18 |
|
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. |
22 |
|
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... |
26 |
|
27 |
(Also, I'm not an expert on this...) |
28 |
|
29 |
The distribution of software, as I understand it, generally has three |
30 |
groups of people who hold it: |
31 |
|
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. |
38 |
|
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. |
43 |
|
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. |
49 |
|
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. |
56 |
|
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. |
61 |
|
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? |
67 |
|
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. |
71 |
|
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. |
76 |
|
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. |
81 |
|
82 |
-- |
83 |
:wq |