I had a great discussion with Mark Hindley about this issue a few months
ago.
I'd like to summarize what I said in that discussion as input to the TC.
But I'd also like to start out by reminding us all what we said in the
GR text that we agreed to.
As one of the contributors to that text, you might either think I'm in a
good or a bad position to interpret it, depending on how you think about
such things.
I think it's clear I've thought about the problem space somewhat.
>However, Debian remains an environment where developers and users can
>explore and develop alternate init systems and alternatives to systemd
>features. Those interested in exploring such alternatives need to
>provide the necessary development and packaging resources to do that
>work. Technologies such as elogind that facilitate exploring
>alternatives while running software that depends on some systemd
>interfaces remain important to Debian. It is important that the
>project support the efforts of developers working on such technologies
>where there is overlap between these technologies and the rest of the
>project, for example by reviewing patches and participating in
>discussions in a timely manner.
We did not say in that GR that we were interested in supporting ongoing
development of sysvinit.
Certainly, in my advocacy post for the winning option, I argued that
didn't make sense to me.
We said only that we were interested in the facilities to allow people
to develop alternate init systems.
(We did not say we wanted to throw sysvinit away either, but the project
did not commit in the GR to interest in sysvinit).
We also said:
>The Debian project recognizes that systemd service units are the
>preferred configuration for describing how to start a daemon/service.
That has been further codified in policy as I'll discuss below.
I'd think that by the time an alternate init system becomes a plausible
general purpose alternative to systemd, it needs to support service
units.
We also said:
Using its power under Constitution section 4.1 (5), the project issues
>the following statement describing our current position on Init
>systems, Init system diversity, and the use of systemd facilities. This
>statement describes the position of the project at the time it is
>adopted. That position may evolve as time passes without the need to
>resort to future general resolutions.
So, the consensus can evolve as we watch what people do, and we see how
valuable development of alternate init systems is.
Personally, I think that an important consideration would be how much
actual development of init systems are we seeing vs how much
maintenance of existing init systems are we seeing.
If we're seeing people who are actively working to solve the problems
that made systemd attractive in other ways, writing new code, that sort
of thing, I'd hope that we would support that work and get it unblocked.
If all we're seeing is maintenance of the same existing init systems, my
personal view is that's not what the winning GR option was about.
Other things we did not say. We didn't say other init systems would be
in bullseye (nor did we say they would not). In my mind, we committed
to allowing developers to experiment, not at this time to making any
particular init system beyond systemd ready for release.
Now, presumably, if someone comes up with some great new init system
that solves the problems that makes systemd attractive over sysvinit to
a number of users in ways that are different/better, we'd probably like
to include it in a release.
If sysvinit's users and maintainers can get it ready to be releasable
we'd probably like to do that, although I don't think the GR applies to
that work so much as the work necessary to allow development to
continue.
I'll close with my comments to Mark, which touch on how this all
interacts with policy as I understand it.
I'm mostly going to avoid value judgments and focus on my understanding
of what Debian decided in the vote and what our policy is, and try and
help you accomplish your goals under that set of constraints.
The short of it is that I think we decided that init scripts are purely
optionalal.
As a consequence, I think that any alternate init system needs to handle
service units, or some significant subset of them, to be useful.
But see below.
I think there are two issues here.
I actually think that you have a reasonably good case for escalating
the NetworkManager support for the virtual logind packages.
In particular, our GR said we were interested in facilitating that
work.
So, I think it would be reasonable to ask what's going on with that and
ask for help trying to work through that.
The init script case is more problematic.
You don't explain why NetworkManager should have an init script,
and the current thinking in Debian policy is that were it a new package,
it probably should not.
Quoting section 9.3.1 of policy:
Packages that include system services should include "systemd" service
units to start or stop those services. See *systemd.service(5)* for
details on the syntax of a service unit file. In the common case that
a package includes a single system service, the service unit should
have the same name as the package plus the ".service" extension.
If the package does not include a service unit (if, for example, no
one has yet written one), including an init script, as described
below, to start the service is encouraged.
Packages including a service unit may optionally include an init
script to support other init systems.
----------------------------------------
So, wishlist bug for an init script seems about right, and "don't want
to maintain and test both," seems like an entirely reasonable
justification for closing that bug as wontfix under the GR text and
under the policy amendments that reflect that.
The policy discussion frowned on removing initscripts without careful
consideration because it could potentially break existing systems.
However, the policy process did not come to consensus on that.
So, I think you have two approaches.
First, if the removal of the init script is breaking existing systems, I
think it's reasonable to engage on that front.
But a maintainer might reasonably ask you to engage in an attempt to get
to an end state of no init script while managing the breakage. So, for
example postinst to detect/warn about situations, documentation in a
news file, etc.
You could also potentially engage on debian-policy and come up with
recommendations for how to avoid breakage in existing packages when
looking at init scripts and considering removing them.
And then if you got consensus on such a change, engage with the
NetworkManager maintainer.
There's one other approach.
If there's some reason that NetworkManager needs an init script more
than other things, that might be worth discussing.
But I think our thinking is that especially for simple init scripts,
service units are the new init script, and anything that comes along is
going to have to deal with that.
Again, very happy to work through this with you, with the understanding
that options may be limited given what we decided.
Attachment:
signature.asc
Description: PGP signature