Re: What is Choice 2 about
>>>>> "Lucas" == Lucas Nussbaum <lucas@debian.org> writes:
TL;DR: Choice 2 is about valuing eventual alternatives to systemd, but
believing sysvinit is a distraction in achieving that.
It's also potentially a compromise for people who want to send some but
not all of the init diversity work to downstreams.
This message contains:
* Response to the orthogonality argument
* How do you get to choice 2
* What might happen if choice 2 passes.
Orthogonality
=============
Lucas> Hi,
Lucas> On 07/11/19 at 13:04 -0500, Sam Hartman wrote:
>> >> Choice 2: systemd but we Support Exploring Alternatives >>
Lucas> What I'm concerned about is that the proposed GR is
Lucas> conflating two different questions that are not completely
Lucas> orthogonal, but quite orthogonal: - whether init scripts
Lucas> must/should/may be included when there's already a service
Lucas> unit - whether exploring elogind support should be supported
Lucas> by Debian Maybe it might be better to unfold the possible
Lucas> combinations that make sense in the list of options.
Rather, I'd say that it has become quite apparent over the years that
when discussing init systems, we cannot even come to consensus on the
questions, much less the answers.
The TC spent a great deal of time and pain trying to come to consensus
on the question and ultimately failed to do even that.
I haven't even tried. The world view and set of questions that leads to
each of the choices I presented is slightly different.
And, as you point out, choice 2 makes this more apparent than the other
choices.
See Simon Richter's messages for a demonstration of exactly how far the
divergence on what questions to answer can get even in the current
discussion.
Getting to Choice 2:
====================
Here's a profile of someone who might support choice 2.
You are concerned about some aspects of systemd. Perhaps it is just
that you're concerned about a mono culture. Perhaps you're concerned
that systemd includes modules that are more tightly integrated than
you'd like; you would prefer something split into more components.
However, you don't think sysvinit is the answer or is an important
point along the path to finding that answer.
We don't have an answer besides systemd today, but you hope Debian will
be part of a laboratory that helps us develop such an answer.
You probably see the value of service units over init scripts. Perhaps
you want something even better long term, perhaps you think service
units would be fine if it was something other than systemd that
interpreted them.
You might think that any future init system will interpret service
units and possibly something new, *not* init scripts.
Choice 2 is about the project being willing to spend the effort to
integrate technologies that provide alternatives to some aspects of
systemd. The work of developing such technologies would of course fall
on the shoulders of people wanting to see them exist. Leaf package
maintainers would get to choose whether supporting such an alternative
made sense for their packages. However,
sometimes integrating such technologies impacts other shared
infrastructure, including systemd itself. If this is something the
project cares about, we'd need to find people willing to follow
discussions, review patches, etc enough that the integration that
touches shared infrastructure could happen.
It doesn't mean that people would need to adopt broken integrations or
integrations that reduced stability for people using the default
configuration; they would just need to provide reasonable review in a
timely manner and work to come up with designs that would meet objections.
The technology where this has been most apparent in Debian recently is
Elogind (and previoustly systemd-shim).
Various other technologies in this space have been theorized on
debian-devel including support for .timer units not in systemd, code to
turn .service units into something else, non-systemd support for
sysusers files.
What Happens if Choice 2 is Adopted
===================================
We'd need to check and make sure that the people in key roles like the
release team and systemd maintainers that have been impacted by these
sorts of integrations lately were comfortable providing timely review
and engaging constructively to resolve objections they raised. If not,
then we'd need to find additional developers willing to help with those
efforts.
It may well be that by the time the vote concludes, the existing integration
issues I'm aware of will be resolved.
In terms of sysvinit support.
It might be that things would look a lot like choice 1. Maintainers are
not required to provide init scripts, but they still may do so. And at
least in cases where an init script can be provided with a working
autopkgtest and the init script is not hard to maintain, I bet a lot of
maintainers would continue to accept the patch. Especially for server
side stuff, I wouldn't be surprised if things continued this way.
On the desktop it might well be that maintainers decide that
compatibility with things other than systemd isn't worth it. This is
likely to be especially true as more systemd features get used like user
units, more socket activations, and more use of security isolation.
So, it might be that if you want to use a Debian-like desktop system
with sysvinit you'd need to turn to a downstream.
A significant question is whether people actually step up and develop
interesting alternatives to systemd features. If there is low effort,
we spend some resources integrating partial alternatives but ultimately
these alternatives do not keep up with the adoption of new systemd
features. If there is medium effort, perhaps we maintain alternatives
for most of the systemd features that are in active use in a large
number of packages, but nothing new or novel gets developed.
If there is sufficient effort or a sufficiently powerful idea, perhaps
we see an alternate way of doing some of the things that systemd does
that is more successful in the market.
There is a significant risk with this choice that we spend project
resources supporting integrating technologies and yet don't end up
assisting with a viable alternative to systemd for a large community of
users.
On the other hand, if you believe that we as a community need novel
alternatives to systemd beyond sysvinit, the risk of doing nothing is
also high.
--Sam
Reply to: