Hi Ansgar,
On 6/27/23 01:45, Ansgar wrote:
[systemd service wrapper provided by init]
I think sysvinit maintainers looked at such ideas in the past, but
weren't capable to get it to work. That might be a blocker for such
approaches. There was also a GSoC project in 2012 and some other work.
I'm fairly sure they are capable of doing that, but there is no point in
doing so. There is already an implementation of the systemd service API,
and it's called systemd.
This interface is not useful as an abstraction layer because it is
tightly coupled with the existing implementation, to the extent that
writing a conforming implementation requires largely making the same
design choices. This work would be redundant, and if we had volunteers
for that, they could be working on systemd instead, that would make more
sense.
The init.d interface, too, is directly tied to an implementation. It can
be implemented by a compatibility layer, which doesn't work the other
way around, but you are losing most of the benefits of the systemd
interface, so the desire to drop this layer is understandable, and has
been predicted (and those predictions rejected as paranoid) back when
systemd was introduced.
There is a fundamental disagreement between the systemd and sysvinit
camps, and it is not at an implementation level, but at conceptual and
community management levels. We cannot implement our way out of this
disagreement.
Fortunately, we don't have to. Proposed policy:
- Each package that contains something that is useful as a systemd
unit should also ship the unit definitions.
There may be exceptions, so I'm writing "should", not "must".
- Each package that contains something that can also be a daemon can,
but does not need to ship an init script.
The maintainer of a service package should know best how to invoke the
program, so there is a technical benefit in having them maintain the
init script, but that only extends as far as their motivation to do a
good job.
- If an init script exists, a service unit with the same name needs to
exist as well so systemd before the removal of the compatibility layer
ignores the init script.
We will have a full release cycle with an old systemd and backports.
- Unit files and init scripts do not need to provide the same
functionality.
The sysvinit users have different requirements than the systemd users.
There are services that have their own implementation of a graceful
restart that cannot be used from systemd, and there are services you
would not find on a machine running sysvinit anyway, so any effort
writing an init script for those would be wasted.
- Maintainers dropping init scripts are asked to file a bug on
orphan-sysvinit-scripts so they can be added there.
Orphaning an init script is just like orphaning a package: you're
handing it over to a team that is not necessarily that invested in your
software as you are, but if you feel you're not doing a good job at it,
stepping down gracefully is expected of a maintainer.
Extending this notion to a part of a package is not a big stretch.
Neither orphan-sysvinit-scripts now! nor the packages it ships legacy
startup scripts for seem to have Replaces or Conflicts though?
The only thing we actually need is a versioned Replaces that allows
orphan-sysvinit-scripts to take over ownership of the conffile.
Conflicts is unneeded here, and the daemon package does not need to
declare any relationship. They can use
Depends: systemd-sysv | orphan-sysvinit-scripts
but really that doesn't do much because orphan-sysvinit-scripts is going
to be pulled in anyway, so I'd rather avoid the clutter.
Less prone to errors than a manual process might be to watch
automatically where legacy startup scripts disappear anyway; it's not
that complicated to do. People tend to forget things.
No, we shouldn't set the bar this low. We're talking about DDs here,
they should all have passed P&P and T&S tests.
Simon
