On Wed, Mar 21, 2012 at 6:55 PM, Walter Dnes <waltd...@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
