Re: BITS from the DPL For September/October 2019
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
Reply to: