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 <florian@???>
wrote:
> On Thu, 18 Jun 2015 16:58:59 +0200
> Mat <mat@???> 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 <slitt@???> 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@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
::
Re: [DNG] Packages aren't the only …
