Re: Dropping SysV init script support? (was: systemd prerelease 254-rc3)

[Tomasz Pala <gotar@xxxxxxxxxx>]

On Mon, Aug 07, 2023 at 15:22:38 +0200, Lennart Poettering wrote:

> It's been 15 years. Stuff that has still not been ported over yet
> should either be declared dead by now or finally be ported over. I
> think this is generally in the interest of users.

+1

BUT having said that:

> or to turn this around: this is only the way how people get off their
> asses and port the stuff over apparently. Nothing else worked for them.

- nothing was truly done to make this happen.


Before removing the SysV-compat glue entirely, there should be
transition period.

0. systemd implements SysV-compat disable knob,
1. distributions use SysV-disabled by default, allowing users to switch
   it on when needed, therefore it's impact is reduced, but notes taken,
2. systemd enables some irritating behavior for SysV-enabled systems,
   like 30 second sleep with console beeping or rotating the screen upside down,
3. systemd removes SysV-compat entirely.


The point is - people don't follow any NEWS, Warnings nor logs, and
then, after some update, they're in a revert-or-die situation.

It's not their fault - no everyone is sysadm, people just want to use
some random packages provided by their vendors.


Gradual transition needs to be stimulated, otherwise you end up with
some boycottsystemd rants. Just-remove approach is nice for programmers,
but contradicts the least-surprise principle without regular users being
warned in step-by-step escalation.

The distributions are important in that process, because each of them
ruling their own defaults makes the process spread over time.
The same reasoning should encourage them to cooperate in the process.

After all, it's better to explain which knob to switch to restore SysV
behaviour, than make it revert-or-nothing.


I know that distros could simply create separate package for
/lib/systemd/system-generators/systemd-sysv-generator
but this won't be noticed unless this subpackage is NOT being pulled
during upgrade, in which case users end up without the actual code
required for SysV-reenable missing in their systems, i.e. much harder to
recover than simple parameter change.


Or - make all the sysv-generated units to ask for password before
execution.

No motivation means no progress.


As a damage control - provide broken_sysv-compat@.service, being simple:

ExecStart=/etc/init.d/%i start

to be explicitly enabled as a last-resort solution.

-- 
Tomasz Pala <gotar@xxxxxxxxxxxxx>