[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [draft] Draft text on Init Systems GR


On Sat, Nov 09, 2019 at 10:01:27AM -0800, Russ Allbery wrote:

> > (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.

Yes, but all of these can be boiled down to required interfaces, "can I
express the desired environment and start conditions in the terms of this

Interfaces are versioned, however, and we need either a negotiation process
or a mechanism to avoid version mismatch. With a slow-moving interface like
sysvinit's, that was not a problem, but systemd evolves faster than Debian
releases. Negotiation is out for static unit files, so that leaves a
lockout mechanism.

In the "full diversity" case, we'd ideally map the required interfaces onto
package relationships, e.g.

    Depends: interface-systemd-timer-unit-1 (>= 4)

Here, 1 and 4 are the version numbers for the interface -- no
compatibility breaks yet, but the unit file uses declarations added in a
later revision. This mechanism could work similar to shared libraries with
symbol versions, and the usual Conflicts/Provides mechanism would make sure
that only one provider for each interface is installed.

Long term, init scripts would lose their special status and require a
dependency declaration as well, which could be used to decide if systemd
generators for init compatibility are needed. A package providing both an
init script and a service unit file would declare that it requires either,
and thus would not force anyone to install compatibility code.

> 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.

The default would still remain systemd. Alternative implementations will
only appear if there is interest in having them, so there is no point in
binding the project into providing them with no users.

My expectation is that alternative implementations will pick and choose
what interfaces to implement, based on users' needs and feasibility.
Basically, if the sysvinit users are mostly running system services on
headless boxes, then there is no need to provide an implementation of
dbus-activated session services.

> > (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?

Probably a package that diverts /sbin/init and replaces it with a shell
script that checks if a transition is pending and performs it if all
requirements are met (e.g. required packages available in apt cache and
checksums correct, ...). No need to do this in existing packages.

> 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.

The transition path is important as long as the installer installs systemd
by default and this cannot be changed (which would be option 1.1.3).

The number "1% of new installations use sysvinit" is floating around. In
absolute terms, that is a massive number of people who went through a long
manual process, and making that process less painful would be a great

> > (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.

As for Policy, not much, since that is an organizational, not a technical

My expectation is that services that require more complex integration than
"start process (after rcS.d|before multi-user.target)" will be
team-maintained anyway, and this is expressing a wish that if a volunteer
pops up who is using that service on a sysvinit box and they are remotely
competent, they get added to the team as the go-to person for sysvinit
integration. That doesn't necessitate commit access, but likely will, and
it probably implies a mail "I'm about to upload a new upstream release, can
you check if it still works?"

I'm reluctant to formulate this as a strict requirement, there will always
be cases where people just can't work together, and forcing them won't
work. That's why I wrote "asked to" -- it's a medium-strength suggestion to
work together if you can.

> > (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?

Agreed, that'd be a last-resort option that at least allows aptitude to
find a conflict-free solution after a few minutes (which is also how you
install libgtk-3-dev without systemd-sysv).

> > (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.

Yes, as a sysvinit user I definitely want it on the ballot. That's the
thing: I'm not just a developer, I'm a user too, and I need clarity.

The problem with intermediate positions is that they do not provide that
clarity. The worst outcome would be "we support sysvinit in principle, but
grant individual maintainers the right to reject patches that make it
work", because that just means burning out people.

> Also, I think that if this is about standardizing on systemd, we should
> just say that, as opposed to speaking in generic terms.

I see that as a technical decision more than an organizational, though. I
agree that it's unlikely that Debian will switch away from systemd as long
as it is the only init system with commercial full-time developers behind

> > (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.

That's the thing: this is a foundational interface, and still nobody has
found the time to move from the informal "as defined by the package" to a
formal "as described in Policy" status in the last four years.

Do we want Policy to document current practice? Then 2.1.1 is a call to
action. Are we fine with delegating parts of Policy? Then 2.1.2 is formal
recognition thereof.

There is no need for Policy changes to be proposed by the systemd
maintainers, in fact I'd prefer if there were more people involved.

> > (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.

I expect that it will be controversial, but I agree that it hasn't been
debated yet. I've added it as it is the next question down the line, and,
if there was a vote on these items, this allows conditional support of
systemd-as-only system (i.e. I could vote MJGNO to express that I'd prefer
a stable systemd to init diversity, but init diversity to a rolling

> > (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.  :)

Yes, that is the extreme of the last axis. Upstream projects have always
moved faster than Debian, and that was fine as long as they were isolated,
which they no longer are. At the same time, it is very hard to get support
from systemd or GNOME people if you aren't running the latest release, so
if we want to stick to stable releases (which I absolutely do) we should
reaffirm that commitment, last but not least to give it a bit more weight
in debates with upstream developers.


Reply to: