[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Matthias's Choice 4

Am Mi., 13. Nov. 2019 um 15:53 Uhr schrieb Sam Hartman <hartmans@debian.org>:
> >>>>> "Matthias" == Matthias Klumpp <matthias@tenstral.net> writes:
> I'd like to understand how what you propose below differs from my choice
> 3.
> This is more or less  along the lines of what I meant to propose with
> choice 3, and I'd like to understand what differences you see that
> matter to you.
> There's a reasonable possibility this can be consolidated with my choice
> 3.
> [...]

I think there are only two differences: 1) My text is *way* more
verbose, making quite specific suggestions on how to deal with some
things, which is probably a bad thing and 2) My text mentions the
other tech in the systemd umbrella project that we may want to explore
TBH, at the point when I wrote this I didn't have the original wording
of your proposal in mind anymore, otherwise I think I would just have
referenced that instead of writing yet another text. Sorry for that!

However, I think it may be useful to highlight in the vote text
somewhere that systemd is actually not just the init system, but a
modular collection of different tools designed to work well together
(many, but not all of them depending on systemd being PID 1), and that
there may be benefit to the Debian operating system in deciding to
adopt some of them, at least on the Linux ports. It's also worth
noting that upstream projects may assume some of the facilities to be
present on systems, and may make the distributor write the integration
glue for non-systemd systems themselves if they don't want to support
a configuration they don't run and test upstream. This makes package
maintenance harder without commitment to some systemd stuff.

On the one hand I think it would be really good to differentiate
between "systemd, the PID 1 daemon" and "systemd, the project, a bunch
of utilities working together and possibly dependent on the systemd
daemon being PID 1" in the vote text. Because that still appears to be
confusing to people (and actually rightfully so, it *is* confusing).
On the other hand, overloading a vote text with too much details is
also not ideal, as that may make the actual intent of an option less
clear in the end (e.g. in my text I could argue that the hint of
"support for other init systems may be split out to separate packages"
really doesn't belong there).

Either way, thank you for preparing this vote! - I was originally more
leaning towards not doing this again, but in the recent threads people
had very good arguments for why this is needed (and from the length of
the thread, that was also obvious).


I welcome VSRE emails. See http://vsre.info/

Reply to: