Re: [draft] Draft text on Init Systems GR
Simon Richter <sjr@debian.org> writes:
> 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."
I voted that option in 2014 and definitely will not be voting that option
today, for the reasons explained in another thread on debian-devel. If
there are a sufficient number of people like myself who feel that way now,
this isn't really a rehash. It's five years later; some things have
changed and we understand more about the problem space.
> The fact that only service start is documented in policy is a bug in
> itself.
There are numerous bugs in Policy in this area and a truly huge amount of
work that needs to be done.
On to your proposal....
> (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.
"Functional dependencies" feels odd to me as a way of characterizing this
whole problem space. I can kind of see where you're coming from with
that, but it's about more than dependencies. It's also about configuring
the environment in which a service should run and controlling the
mechanisms of starting the service and determining when it should be
running.
The phrasing here doesn't really address how aggressive we're going to be
about using systemd services. I think "if possible" is doing a bit too
much heavy lifting and not providing enough guidance.
> (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.]
Doesn't this have that same problem that it votes for creating an RC bug
that we have no real idea how to fix?
In general, for these variants, is the transition path from systemd to
sysvinit something that is controversial in the project? I thought the
problem was mostly ensuring things work on sysvinit at all.
> (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.
I truly have no idea what this means, what Policy language it would
translate into, or what work this implies a Debian package maintainer
should do.
> (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]
This seems fraught with technical peril. Are we sure our package
dependency resolution code is capable of dealing with this tangle of
Conflicts and Provides?
> (Option 2)
> The Debian project aims at providing a tightly integrated operating
> system, standardizing on specific components to ensure the availability
> of basic functionality.
I think it would be interesting to have this sort of "all in on systemd"
option on the ballot to understand how many people in the project may feel
this way but be unwilling to wade into the interminable threads, although
it feels kind of aggressive as only one of two choices.
Also, I think that if this is about standardizing on systemd, we should
just say that, as opposed to speaking in generic terms.
> (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.]
We've always done a combination of these two things based on a lot of
factors: how foundational the interface is, how much time the relevant
teams have, etc. I'm not sure it makes sense to collapse this waveform
quite this definitively.
> (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]
This is an interesting question but I'm not sure it needs to be decided by
GR. Is this really that controversial? I'm not sure we've spent much
time talking about it to see if we can reach a normal consensus.
> (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]
This is a bit of a bombshell to drop into the middle of this GR. :)
> 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.
Yes, I think this is right.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: