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
