Re: [draft] Draft text on Init Systems GR
Hi,
the main problem I see with this GR is that it is in essence a rehash of
the GR[1] we had in 2014, with pretty much the same options minus the one
that won, "A GR is not required."
> Choice 1: Affirm Init Diversity
The way this is worded is even stronger than in the 2014 GR, which made
allowances for degraded operation, because it was already obvious then that
GNOME would tightly integrate with systemd.
We cannot sensibly pass this as a resolution because it would create tons
of highly complex RC bugs, something the 2014 GR proposal explicitly
avoided, so this would just set us up for another GR reversing the decision
in light of its total unworkability.
> Being able to run Debian systems with init systems other than systemd
> continues to be something that the project values. With one
> exception, the Debian Project affirms the current policy on init
> scripts and starting daemons (policy 9.3.2, 9.11).
This is the smallest part of the problem. If it was about starting daemons,
we'd have found a solution already.
The question is what we do with packages that have an explicit functional
dependency on a particular feature only implemented in one particular
service orchestrator (because systemd is definitely more than a pure init
system, it just happens to include one as a byproduct).
The fact that only service start is documented in policy is a bug in
itself.
The question at this point is no longer "which init system do we want to
have", but "who sets policy for package integration?" -- and that is a
question that will have to be answered even in a systemd-only ecosystem.
So as a counterproposal, two major directions for diversity yes/no (with no
middle ground, and two further questions for each, then flattened out to
make use of the fact that we're using Condorcet and don't have to deal with
tactical voting.
(Common)
The Debian Project recognizes that several upstream software projects are
converging on a common service orchestrator architecture and therefore
require distribution maintainers to ensure that compatible interfaces are
provided when the software is installed. At the same time, users are
deploying Debian in environments where a hard dependency on a specific
service orchestrator either introduces additional complexity or conflicts
with other software.
[Rationale: we want to be the universal operating system, which includes
desktop, server, container and embedded setups, probably a few others, and
mixes between them. For desktop users, we need a default installation that
is fully functional, but container solutions have their own dependency
tracking across machines, and will make different decisions on which
services to deploy where than a standalone desktop system would make.]
(Option 1)
The Debian Project aims at providing the greatest configuration flexibility
while maintaining a sensible default installation for end users. To that
end, we document functional dependencies in a machine-readable way and
provide alternative variants if possible.
[Rationale: not every combination of software makes sense or has sufficient
interest to be maintained, and that is okay, but if there are users, we
should try to support them.]
(Option 1.1.1)
Automated variant transitions shall be supported.
[Rationale: moving from systemd to sysvinit is currently an involved manual
process, so unavailable to anyone not already skilled in Unix
administration, creating an artificial barrier.]
(Option 1.1.2)
Moving installations between variants shall be supported.
[Rationale: this is what we have now, so it probably should be an option]
(Option 1.1.3)
Installation variant is decided at installation time and there is no
expectation that this can be altered later.
[Rationale: this allows us to write package dependencies without regard for
conversion paths, and also gives administrators a scriptable path for
deployments, which they currently do not have.]
(Option 1.2.1)
Package maintainers for packages requiring tighter integration into a
particular ecosystem are asked to form teams to cover adequate integration
testing.
[Rationale: we're moving towards team maintenance in git anyway for many
packages. If someone volunteers to maintain a particular variant that they
also use, then that should probably work.]
(Option 1.2.2)
Package maintainers are asked to merge patches implementing support for
different ecosystems. Bug reports for problems arising on these variants
may be forwarded if they are packaging related.
[Rationale: this is like team maintenance, but with a hierarchy and lower
barrier to entry, in the hope that derived distributions send patches to
minimize differences]
(Option 1.2.3)
The same software may be packaged multiple times by different maintainers
if integration requirements cause incompatibilities.
[Rationale: this allows packaging to be kept simple, at the expense of some
space in the archive]
(Option 2)
The Debian project aims at providing a tightly integrated operating system,
standardizing on specific components to ensure the availability of basic
functionality.
[Rationale: if we want to use new APIs, we need to make sure they are
available. While there are replacements for some interfaces, there aren't
for all of them, and likely never will be.]
(Option 2.1.1)
The available interfaces for each Debian release are defined in Debian
Policy.
[Rationale: this is how we have always done it: Policy explains the
interfaces for package integration]
(Option 2.1.2)
The available interfaces for each Debian release are defined by the
maintainers of the packages providing them.
[Rationale: the maintainers of these packages have the best overview over
which interfaces can be best supported for the support period of a
release.]
(Option 2.2.1)
Core system components are excluded from backports, and backported packages
need to be compatible with the interfaces provided by the stable release.
[Rationale: it's a stable release.]
(Option 2.2.2)
It is permissible for backports to declare a dependency on a newer version
of a core system component. Users installing a backported version of a
service may be required to pull in backports of other packages.
[Rationale: interfaces change, and it may not always be possible to combine
two components from different releases]
(Option 2.2.3)
Debian switches to a rolling release schedule and requires that components
are upgraded in lockstep.
[Rationale: that is what we can get upstream support for across all
projects]
These options would be packaged as follows:
A - (1 1.1.1 1.2.1) Diversity, automated switchover, form teams
B - (1 1.1.1 1.2.2) Diversity, automated switchover, integrate patches
C - (1 1.1.1 1.2.3) Diversity, automated switchover, parallel packages
D - (1 1.1.2 1.2.1) Diversity, manual switchover, form teams
E - (1 1.1.2 1.2.2) Diversity, manual switchover, integrate patches
F - (1 1.1.2 1.2.3) Diversity, manual switchover, parallel packages
G - (1 1.1.3 1.2.1) Diversity, no switchover, form teams
H - (1 1.1.3 1.2.2) Diversity, no switchover, integrate patches
I - (1 1.1.3 1.2.3) Diversity, no switchover, parallel packages
J - (2 2.1.1 2.2.1) systemd only, units in policy, no systemd in backports
K - (2 2.1.1 2.2.2) systemd only, units in policy, backports can upgrade
L - (2 2.1.1 2.2.3) systemd only, units in policy, rolling release
M - (2 2.1.2 2.2.1) systemd only, package is policy, no systemd in backports
N - (2 2.1.2 2.2.2) systemd only, package is policy, backports can upgrade
O - (2 2.1.2 2.2.3) systemd only, package is policy, rolling release
P - Further Discussion
In principle, the "should interfaces live in policy or be defined by
packages" and "are backports of core components allowed" questions are also
relevant for the "diversity" case, but would probably take a backseat
compared to more pressing issues.
I'd also like to ask about what should be the scope of the Debian project
at some point, but that should probably be an indicative vote first rather
than an immediate policy decision so that people can make up their minds.
Do we (actively) support
- GNOME desktop users
- KDE desktop users
- other (non-FDO?) desktop users
- standalone servers
- servers in a group
- non-systemd (Docker, OpenVZ) container installations
- externally coordinated (Kubernetes, ...) installations
- systemd container installations (i.e. containers with access to outside
systemd)
- embedded device builders
- mixed systems (e.g. desktops with virtual machines or laptops running a
database server for some application)
- derived distributions
- throwaway chroots for compiling
- non-Linux kernels
- non-PC architectures
Each of these imposes constraints on packaging, and juggling all of these
seems to cause a lot of extra work, so at some point we need to decide what
users can expect to work and when to move to a specialty distribution. That
time is not now though, because there has not yet been a debate about it.
Init diversity on the other hand has truly been debated to death, and we
need to make a policy decision here. Running sysvinit has been a death of a
thousand paper cuts because every time something broke, it was argued that
it was improper to demand anything from volunteers. So either we decide
that we want full init system diversity or not, in either case volunteers
are free to decide whether to invest more time or find their fulfillment
elsewhere -- that will be healthier for the project in the long term than
the continuing frustration of having one's work rejected.
Simon
[1] https://www.debian.org/vote/2014/vote_003
Reply to: