Am Mi., 13. Nov. 2019 um 11:55 Uhr schrieb Holger Levsen
<hol...@layer-acht.org>:
>
> On Tue, Nov 12, 2019 at 09:51:03PM +0500, Alexander E. Patrakov wrote:
> > Choice 4: systemd without Diversity at all
>
> as said before, I dislike the 'without diversity' framing and think it's
> wrong, misleading and insulting. So I'd rather propose 'focus our efforts
> on systemd' or 'systemd and overcoming technical debt' or whatever.
>
> systems running systemd vary a lot and have a *lot* diversity.
>
> similarily I would also *not* call sysv bad names or frame it badly.
> (and maybe even calling it 'technical debt' is not a good idea.)
Exactly this. I think I would definitely second a "focus on systemd"
amendment which makes packages support systemd as a priority, but
doesn't force out sysvinit or any other init system from the archive.
I think there's a valid point in having them, and as long as they
don't impair the default init system and people aren't forced to do
work they can't test, it's fine to have them.
So, something like this maybe? (adapted from Alexander E. Patrakov's text):
```
Choice 4: Focus on systemd as init system and features requiring it
The Debian project recognizes that systemd service units are nowadays
the preferred configuration for describing how to start a daemon/service.
Packages should include service units. At the same time,
the Debian project acknowledges that maintainers and upstream developers
are often unable to provide high-quality (or any) support for alternative
init systems in their packages on their own and can not or do not test
that their
packages work under such init systems. It is not realistic to expect
the situation to improve, and Debian does not want to block
experimentation with new Linux-based technologies developed under the
systemd project umbrella or hinder their adoption by requiring all
other init systems to support the same features as well (which may not
even be desired by those projects).
Therefore, Debian should focus on a polished experience with systemd
as init system as first priority. Other init systems will remain
available as long as there is enough interest by people to maintain
them. Package maintainers are encouraged to accept patches to support
non-systemd configurations, as long as the changes do not impair the
user experience when systemd is available. Package maintainers may
split out support for alternative init systems into separate binary
packages. Maintainers of other init systems are encouraged to test
support for their configurations if the package maintainer can not do
it.
Debian is still committed to working with derivatives that make
different choices about init systems.
```
This would mean that it's not a bug if no sysvinit script is provided
by a package and only a systemd unit is available. Also, if a sysvinit
script is faulty, such an issue would be a normal/important bug and
wouldn't get a package removed or excluded from release. At the same
time, maintainers of alternative init systems could add support for
their systems, as long as they test it (CI/autopkgtest may help
there).
Any alternative init system would very much be second-class, but so
are alternative kernels, or compilers, or libc implementations, or
architectures (or desktop environments, some would argue), and that
doesn't stop people from doing awesome work on them. And if we ever
want to switch away from systemd to something else, we still could -
but until then, the experience with it should be as good as we can
possibly make it.
This is not a finished proposal, but something I would be much more
likely get behind compared to a "systemd and completely screw
everybody who wants something else by policy" approach.
Cheers,
Matthias
--
I welcome VSRE emails. See http://vsre.info/
