Thanks much for the detailed explanation. Response below. On 8/16/20 10:38 PM, Eli Schwartz via arch-general wrote:
The sysvcompat symlinks still installed are: - halt - reboot - poweroff - shutdown - init
These programs are generically useful on fully systemd systems, and systemd documents them as such:
"These commands are implemented in a way that preserves basic compatibility with the original SysV commands. systemctl(1) verbs halt, poweroff, reboot provide the same functionality with some additional features."
When it comes to telinit, the description is, rather:
"This is a legacy command available for compatibility only. It should not be used anymore, as the concept of runlevels is obsolete."
Hmmm ... OK. I wasn't aware that telinit was now being considered legacy/deprecated. I've habitually used it for years to drop to single user mode, which I do every time before I perform a system update with pacman. I guess I'll have to find some other command to do the same using systemd. (I think they call it rescue mode, rather than single user mode.) Thanks, DR
It seems clear to me why it's no longer installed except when systemd is configured with the necessary code to interpret and convert old /etc/init.d and /etc/rc.d infrastructure into stubbed systemd units.
As for whether systemd should provide a split sysvcompat package that provides symlinks for generally useful programs styled after sysvinit, or, alternatively, provide the full-blown HAVE_SYSV_COMPAT initscript parser etc? Personally, I don't believe the split is useful anymore, as I believe it was originally meant for the sysvinit -> systemd migration period to allow having both installed at the same time and easily switching between the two. I'd rather remove it entirely, and fold it into "systemd". It's required by "base" anyway, lol.
I don't believe the intention is to provide runtime generation of systemd units, and I think the pkgdesc is misleadingly simple in that regard.
...
Anyway, if you want to have dialogue about whether it's useful to have a telinit program, regardless of upstream's defaults, by all means, feel free to have that discussion.
But can it please not include rationalizations like "why are we deviating from upstream by not including it"?