Re: Policy consensus on transition when removing initscripts.
Hi,
On 6/25/23 23:15, Mark Hindley wrote:
The most recent proposal[6] for updating the Policy with a requirement to use
tmpfiles.d(5) states
"Init systems other than ``systemd`` should allow providing the same
functionality as appropriate for each system, for example managing the
directories from the init script shipped by the package."
The way I see it, we are getting a split between "daemons" and
"services", and it simply does not make sense to start a "service"
directly from an init script, because it requires the service
orchestrator as its runtime environment.
Init scripts are useful for starting daemons. If you need a service
started, you need an appropriate service wrapper, and that is outside
the scope of an init system. The lack of these interfaces is not a
deficiency, but a deliberate design decision.
My expectation is that some daemons will gain some systemd integration,
but keep the non-systemd code because it is still useful during
debugging and in container environments, and init scripts would use the
non-systemd invocation interface.
This creates an inconsistency whereby non-systemd inits are required to provide
functionality in their initscript, but that initscript is not required to be
present.
"If it is present, it also needs to work." sounds like a reasonable
statement though.
Simon
Reply to: