Hi, On Tue, Oct 29, 2019 at 10:38:32PM +0100, Thomas Goirand wrote:
> If we have such vote again, I'll continue on this direction: I'd prefer > if we didn't have to vote. >From a Policy perspective, packages are supposed to integrate into the system by providing init scripts, and Policy has a lengthy definition of how init scripts need to behave. We need to at least mention systemd unit files at some point, so action is needed, and that action needs to be backed up by a vote to avoid being more divisive than necessary. So far, systemd adoption has been mostly smooth sailing because the ecosystem effectively consists of two blocks: the systemd core, which is centrally coordinated, and some traditional Unix daemons hanging off it, but essentially not integrating. This is about to change as projects actually start using systemd. For example, libvirt needs to tightly integrate with systemd because a lot of the automatisms for the desktop are actively harmful in a VM hosting setup. My VM host starts with two visible network cards, loading the driver enables fourteen more virtual functions, so I start with sixteen Ethernet devices, fifteen of which need to be completely ignored by systemd-networkd, and one has static configuration. When VMs start up, LVM logical volumes are activated, but should not have fsck run on them, because they are then having their permissions changed so KVM can open them exclusively and make them available to the guest. The virtual network cards then have their drivers unbound from them, making the interface disappear, and the PCIe device is passed through to the guest. In addition, libvirt creates a tap device, and connects it to a bridge device whose IP configuration lives inside libvirt's configuration database. All that requires way more complex unit files than anything we normally deal with in Debian, and we need to decide how much control we want to keep over package integration here, because that is what Debian does: take upstream software and provide a coherent integrated whole. By leaving it unspecified in Policy what systemd features are expected in a particular Debian release, we essentially take a back seat in what should be our core competence. At the very least, I'd like Policy to spell out what types of unit files are supported, what keywords in those unit files exist, and what target names are used to denote certain points in the boot sequence (similar to how we define priority ranges for init scripts). We probably don't need to replicate the full documentation for these things, but we are deviating from upstream systemd by doing stable releases, and we need to at least document the deviation. We should probably also make some inroads into when unit files should specify dependencies and which. Systemd explicitly differentiates between functional and order dependencies, and lots of daemons just specify both. Are these required, or just cargo-culted from somewhere? I'd expect Debian maintainers of services that ship unit files to understand exactly what these dependencies do, and whether they are needed, and that means adding that information to Tasks&Skills in the New Maintainer process. All of these are exactly the kind of bureaucracy that Debian is (in)famous for, but which has enabled us to build a high-quality distribution, and which will be necessary going forward if we actually want to use more of systemd's features and still keep our reputation. In my opinion, keeping the other init systems around is also still useful, because there will always be installations where the default behaviour of systemd is counterproductive, and keeping the system running after updates is playing whack-a-mole with newly introduced features that also need to be turned off. If the project feels that these use cases are not worth supporting, then that is a policy decision that needs to be voted on, not just silently implemented, last but not least so we can update our marketing materials with footnotes on the "universal operating system" tagline, and users (who, after all, are one of our priorities) can adjust their expectations. So yes, having a vote is necessary at this point. We've neglected setting policy way too long, the scope of the project is unclear at this point, and people are pulling in all kinds of directions. Simon
