Steve Langasek <vor...@debian.org> writes:
> So to make my position clear: L does not accurately reflect what I
> think we should be doing; but given the option between L and T, I was
> willing to vote L above FD and was not willing to vote T above FD
> because I think T unambiguously sets the stage for all other init
> systems to wither away in Debian and I think it's foolish for the TC to
> say they are "welcome" under such circumstances.
I completely understand how you would end up in that situation.
> Here's what I think is the right technical policy, that we should be
> addressing with this resolution.
> - Packages in jessie must retain compatibility with sysvinit startup
> interfaces (i.e., init scripts in /etc/init.d).
> - Packages can require other interfaces for their operation that are
> provided by an init system implementation, but which are unrelated to
> service management; however, these requirements must be expressed in a
> way that does not tie them to a single init system package. E.g., a
> package that uses the logind dbus interfaces is absolutely free to do so,
> but must not express this usage as 'Depends: systemd'.
> - The TC should make no ruling at this time regarding releases beyond
> jessie.
Here is the language that I came up independently of (and before) your
message, which I think demonstrates how close we actually are on this
point.
The following is technical advice offered to the project by the
Technical Committee under section 6.1.5 of the constitution. It does
not constitute an override of maintainer decisions past or future:
Packages should normally support the default Linux init system. There
are some exceptional cases where lack of support for the default init
system may be appropriate, such as alternative init system
implementations, special-use packages such as managers for non-default
init systems, and cooperating groups of packages intended for use with
non-default init systems. However, package maintainers should be
aware that a requirement for a non-default init system will mean the
package will be unusable for most Debian users and should normally be
avoided.
Package maintainers are strongly encouraged to merge any contributions
for support of init systems other than the Linux default, and to add
that support themselves if they're willing and capable of doing so.
In particular, package maintainers should put a high priority on
merging changes to support any init system which is the default on one
of Debian's non-Linux ports.
For the jessie release, all packages that currently support being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so. Reasonable changes to preserve or
improve sysvinit support should be accepted through the jessie
release. There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and the
package is still basically functional. All packages should support
smooth upgrades from wheezy to jessie, including upgrades done on a
system booted with sysvinit.
The Technical Committee offers no advice at this time on requirements
or package dependencies on specific init systems after the jessie
release. There are too many variables at this point to know what the
I think this is broadly similar to what you propose above. The
differences I can identify are:
* I don't explicitly require that all dependencies on non-init
functionality provided by the init system be redirected through a
virtual package immediately. I think this is an implementation detail;
I don't have fundamental objections to your language, but I do think
it's overspecified. I think we get to the same place with the above
advice, combined with the stronger advice for jessie.
* We deal with the question of what happens if logind without systemd
fails to materialize in slightly different ways. I approach that with
the "technically feasible" language, and you approach that by allowing
for a dependency that can only be satisfied by one package. I think
either of those are reasonable approaches. My language tries to avoid
specifying the technical solution and instead tries to state the desired
result.
In general, I would be happy to use my language, your language, or some
merger between them. There are some things I prefer about how I put this,
but the only thing that I'd really like to change is to give the
maintainer some discretion over your first bullet. You sort of do this
already by saying "retain" rather than saying that packages must support
sysvinit, but I think I was somewhat clearer. I don't see any reason why,
say, mountall or socklog-run should be required to support sysvinit.
My statement is written using 6.1.5 because it sidesteps the whole issue
of delegations and whatnot and I think should be an entirely
uncontroversial power of the TC, and I don't think anything stronger than
advice is actually needed. If we still end up with conflicts, we can
cross that bridge when we come to it, but I don't think that's likely.
However, if people feel strongly that this should use 6.1.1 instead, I
don't think it makes a huge difference. I do think that invoking 6.1.4
would be inappropriate (and I think there's general consensus there; I
don't believe anyone is intending for us to override anyone at this
point).
> I'm not trying to tell maintainers they can't use native service
> management interfaces to systemd or upstart post-jessie,
This is the biggest thing that bothers me about L, so that's, from my
perspective, a huge step towards something that I can get on board with.
> but I do think we need to make clear what's expected for jessie, if for
> no other reason than because of the upgrade requirements (which AIUI you
> agree with - or did, earlier in the discussion).
Yes, I completely agree with this.
> And I don't object at all to packages using logind - logind itself is a
> very good thing! - but if we actually intend to be open to alternative
> init systems, then maintainers should be expected to do the bare minimum
> of work (i.e., declaring dependencies appropriately) required to leave
> the door open for this.
I agree with this as well, and I think the only difference between your
text and my text is how we'd word it.
> Multiple init systems are viable today only because we have a common
> baseline interface, defined in Policy. Once we allow packages to drop
> support for sysvinit in favor of native systemd units, we no longer have
> a least common denominator interface. Init systems that can't handle
> systemd units directly are going to have an insurmountable disadvantage.
> This is not assuming bad faith, only human nature - as soon as sysvinit
> is not the default and sysvinit compatibility is no longer a policy
> requirement, support for non-systemd init is going to bit-rot in the
> archive, because it's no longer a development priority; some maintainers
> will even stop shipping init scripts as unsupported/untested, or because
> they're known broken and no one has stepped forward to update them. The
> shift of responsibility from individual maintainers to take care of
> their init scripts for proper functioning, to some hypothetical
> community of init system afficionados, is not a trivial thing.
To the extent that this is what will happen, and I'm not entirely
convinced that it's as dire as you believe, I think exactly the same
argument applies to upstart. In other words, this particular issue is not
dependent on what init system we choose, provided that the init system is
not sysvinit. All three alternatives have considerably superior init
system syntaxes, and all of them are mutually incompatible.
My feeling here, and the reason why I'm not as pessimistic as you are, is
that I think maintaining both a systemd unit file and an upstart init file
is considerably less work than maintaining a single sysvinit init script.
Both upstart init files and systemd unit files are quite simple for the
typical daemon and will not pose any major ongoing maintenance work. I
think both are simple enough to be akin to doc-base files, which I
maintain in all of my packages where appropriate despite the fact that I
never run any program that uses doc-base and literally never test them.
This is possible to do with a sufficiently simple syntax. I don't think
it really works with current sysvinit scripts.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
