:: Re: [DNG] powerdns upstream has dro…
Inizio della pagina
Delete this message
Reply to this message
Autore: tito
Data:  
To: dng
Oggetto: Re: [DNG] powerdns upstream has dropped sysvinit support
On Thu, 12 Oct 2023 13:41:07 +0300
Boian Bonev via Dng <dng@???> wrote:

> Hi,
>
> > > I would suggest instead rather than orphan-sysvinit-scripts, s6
> > > scripts, runit scripts,
> > > who knows scripts... to create a collection of definition files per
> > > service
> > > with the needed variables (needs, provides, daemon, options to run
> > > in foreground,
> > > options to run in background, options to log, options for pidfile, 
> > > run as user, run as group,
> > > you name it option, option I forgot, runit_specific_options,
> > > s6_specific_options) that could be
> > > sourced by sysv, runit, s6 and others  to avoid duplication of
> > > effort and don't
> > > waste manpower.
>
> ..cut..
>
> > You do make a valid point. One of the reasons for the fast adoption
> > of
> > systemd has been the easy interface (service files) for developers
> > and
> > packagers.
> > The fastest way to make inroads with an alternative init imo is to
> > adopt
> > the service file format from systemd (and embrace, extend, and
> > extinguish?).
>
> I was planning to write a reply in a similar spirit to yours ;)
> Moreover those service files are already there and besides the
> respective interpreters there is no extra work to do per package.
>
> The main problem in supporting systemd service files is that there are
> concepts in them that other init systems can not (easily) handle and it
> will become a race of adding that support versus more non-standard
> stuff coming...


Hi,

I think this way you will be always dependent upon systemd upstream
decisions and so you are in the same position as today.
What we need is a well designed common unified declarative
init system service format that takes into account the needs
of the different init systems and once it is standardized
due to the rule of maximum laziness it will be adopted
by everybody because it is supported by several init systems
and their developers.
Just to be clear I don't think I would be able to do this myself,
maybe just for sysvinit, but I lack the knowledge about other init
systems due to the fact that my experience derives mainly from
running my own little work and domestic networks.

Ciao,
Tito

> With best regards,
> b.