Re: Integration with systemd
On 11/1/19 3:20 PM, Simon Richter wrote:
>> If we do need to have a GR, we need to be very careful how the choices
>> are worded. We should be clear whether we are giving carte blanche
>> for Debian developers to use every possible systemd feature under the
>> sun, whether or not there are non-systemd emulation possibilities yet.
>
> Taking off the "I'm running sysvinit" hat, and putting on the "if we're
> going to do this, we should at least do it properly" hat: The obvious
> middle ground would be to allow features that exist in the previous
> release, so we can have working backports.
There's no need to do that. If a backported package is using such
features, then it just should depend on the correct version of systemd.
You may have seen that systemd 242 is already in buster-backports...
> It absolutely makes sense to teach start-stop-daemon to parse a .service
> file instead of its command line, that is a net win for everyone. If unit
> files can have shebang lines, we could even use them as init scripts
> directly, and that would probably cover 90% of use cases for bullseye
> without adding any more emulation features.
If you want to do a good thing for sysv-like stuff, then IMO, you'd
better work on having OpenRC to replace sysv-rc. That'd be a real net
improvement, and from there, you could improve OpenRC to have it in
feature parity with systemd. Then we could simply drop sysv-rc.
Later on, I don't think it'd be so hard to write a .service -> runscript
converter. The declarative way of OpenRC is very close to the one of
systemd, even though the internals are very different. Then init script
could start slowly dying too, for good! :)
If only I had spare time, I'd have work on that and have that ready for
Buster... Maybe this can be achieve for Bullseye? (I do have enough on
my plate with OpenStack, and I'm convince my time is better spent there)
Cheers,
Thomas Goirand (zigo)
Reply to: