On 8/16/20 9:30 PM, David Rosenstrauch wrote:
There's no need to be rude. I didn't ignore your email, and I snipped it from my response for brevity's sake to spare the list from unnecessary sprawl.
There is no ambiguity here. You suggested that this change causes Arch to deviate from upstream. The part you snipped explained how it does not, in fact, deviate from upstream. A couple of lines isn't huge sprawl. But I wouldn't care if you quoted it or not, as long as your response made it likely you read and internalized it... But, you went from me saying this (snipped) "the upstream install layout no longer includes these" [telinit cmd/man] to you responding with "Shouldn't it [arch] still? (And wouldn't it be deviating from upstream if it didn't [provide telinit]?)"
But near as I can tell, what you wrote isn't entirely accurate. It's not that upstream no longer includes them; it's that it no longer includes them *by default*. So rather than the package always building the telinit and runlevel binaries, it looks like it now *optionally* builds them depending on whether the HAVE_SYSV_COMPAT flag is set (to indicate whether you want to include sysv compatibility or not).
But since the package in question is called "systemd-sysvcompat" and is intended to provide "sysvinit compat for systemd", it's puzzling to me why Arch would choose to explicitly *not* set that flag when building that package. The telinit and runlevel commands were part of the Linux sysv init system for ages, so I'm not clear what would be the point of suddenly removing them from a package whose whole intent is to provide sysvinit compatibility. I mean, if someone doesn't need or want sysvinit compatibility, then they just wouldn't install that package altogether. And if they did install it, then presumably they'd expect those two utilities (whose build is explicitly triggered by a flag indicating whether systemv compatibility is desired) to be included.
The preprocessor macro HAVE_SYSV_COMPAT does a *lot* more than provide some symlinks. 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." 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"? -- Eli Schwartz Bug Wrangler and Trusted User