Has anyone taken a look at pleaserun? Link: https://github.com/jordansissel/pleaserun. It's made by the same person who wrote fpm (Jordan Sissel). It lets you generate init scripts for a plethora of different inits, given only the installed location of the binary.
-Jude On Thu, Jun 25, 2015 at 7:50 PM, Florian <flor...@zwischenspeicher.info> wrote: > 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 > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
