[arch-general] Telinit?

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200816/d2eb7a66/attachment.sig>