On Thu, 18 Jun 2015 16:58:59 +0200 Mat <m...@parad0x.org> wrote: > So in general I think that this approach - moving init system specific > things out of the main package and providing one package per init > system > - is a good way of supporting multiple init systems. > > For instance: > openssh-server - the ssh daemon, stripped of its startup > script openssh-server-sysv - the traditional sysvinit startup > scripts openssh-server-run - startup scripts for runit > openssh-server-epoch - startup scripts for epoch > openssh-server-openrc - startup scripts for OpenRC > openssh-server-systemd - why not? > etc..
Hello diversity! It's quite for a while that I'm reading this formidable list, now it's time to spend my actual two cents: Since I've read the following mail from the "epoch feature request" thread... On Wed, 17 Jun 2015 11:25:28 -0400 Steve Litt <sl...@troubleshooters.com> wrote: > Here is the sum and total of information that could ever be needed for > an Epoch Object (service, thing, whatever): > (...) > > Most of the preceding can safely be left to its default and remain > unmentioned. Some of it is defined by the LSB header. My point is, by > the time all is said and done, an Epoch object is pretty darn simple, > pretty much like a systemd unit file (which is probably what we > *should* kidnap as our source of conversion data). ...I wonder, if it is necessary to create that many (daemon*initsys) packages, as Mat (and others?) proposed - or if it was possible to create some standardized per-daemon config file, to be parsed by init-system-specific scripts into suitable configurations / init- scripts. On the long run, these "universal" definitions could be maintained with their respective daemon, while the particular parser-scripts might become part of the init-systems, possibly as an extra package. This should provide a simple way of solving package dependencies, while bringing greatest flexibility, if these init-system-specific scripts were invokable in some interactive mode, asking the user (or a higher- level configuration tool) which daemons to take care of. Disclaimer: I'm more of an advanced user than a developer, but willing to get my hands dirty if this idea should prove to make sense for at least a subset of the existing (and upcoming:) init-systems, perhaps even including systemd. Regards, Florian -- "A specialist is a barbarian whose ignorance is not well-rounded." Stanislaw Lem, His master's voice
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
