Bug#727708: init system discussion status
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Bug#727708: init system discussion status"):
>> Another issue, which I did not address here but which we should
>> probably say something about, is that the init process 1 implementation
>> and the system used to run daemon configuration and startup jobs is
>> separable, and in fact is separated in OpenRC. We should be clear
>> about what we're talking about, particularly when it comes to non-Linux
>> ports.
> I'm not sure what kind of things you are proposing should be in the
> resolution text (or, what in my proposal is wrong). Is it not
> sufficient to say that people should accept openrc patches as and when
> the openrc policy is done ?
Thinking about it some more, I think the only other place where this
affects the decision is if we want to say something about requesting that
the non-Linux ports adopt the same init system if they both can't use the
default. We presumably wouldn't want one of them using sysvinit and the
other one using OpenRC, since then we're potentially supporting three
different default init systems from the perspective of what init system
means to packagers (what syntax the configuration files are in).
>> One possibilty is to explicitly say that we'll make it ourselves after
>> the jessie release.
> I don't want to do this in case it turns out to be uncontroversial.
Good point. I think we can just drop the mention.
>> I'm not at all fond of this approach. Neither the upstart nor the
>> systemd notification processes are so unreasonable as to warrant the TC
>> explicitly asking the projects to change their designs.
> I think that's not the right the question. The real question is this:
> Are the protocols offered by systemd and upstart each so plainly
> reasonable, that we are willing to overrule a maintainer who feels they
> protocol they are asked to support is too ugly or burdensome ? Are such
> a maintainer's objections so unreasonable ?
Ah, okay, I see what you're getting at.
I think they are. Furthermore, I don't think there's any likely prospect
that either will adopt a socket-based synchronization protocol other than
systemd's, so saying that these aren't patches maintainers are required to
take pretty much says that maintainers aren't required to integrate with
the synchronization protocols.
We could do that. In general, I'd really prefer to defer to maintainers
on what they're willing to integrate with. I was somewhat leaning in that
direction earlier, in that I'm worried pre-deciding that we're going to
force maintainers to do something that might never happen just raises the
discomfort level to possibly no purpose. But you're correct that it's
setting up a situation where some maintainers could make life difficult
for projects that people care about, and result in further arguments
appealed to the TC, which is uncomfortable for everyone involved.
My inclination would be to give maintainers technical advice to accept
integrations with either existing synchronization protocols, but leave it
as technical advice rather than the binding part of the decision.
>>> | Failure to apply reasonable patches, including failure to explain
>>> | promptly and constructively why a patch is not reasonable, is
>>> | likely to lead to the maintainer being overruled. ]
>> I think we already covered this with "should" in the first sentence of
>> this section without needing to make an explicit threat.
> I would like to include this because it will stiffen our resolve.
I must admit I'm not particularly interested in having my resolve
stiffened.
> It also includes the important point that it is up to the maintainer to
> justify non-inclusion, not the other way around.
I guess the question here is how many conflicts we anticipate and whether
it's worth being somewhat confrontational ourselves to head it off. If
there aren't conflicts in practice, we're just creating conflict without a
need. I don't think it matters a tremendous amount, though.
> The main practical reason for ruling this out, and converting existing
> packages, is that not all the ports of upstart can be expected to
> implement the underlying strace mechanism used by upstart to implement
> these.
Oh, good point. I forgot about that.
>>> | Cross-init-system compatibility:
>>> |
>>> | 10. Debian contributors are encouraged to explore and develop ways in
>>> | which a package can provide support for non-forking startup in
>>> | multiple different init systems without having to have separate
>>> | support for each init system in the source package; and, ideally,
>>> | without having to have separate support for each init system in the
>>> | binary package.
>> I don't see anything objectionable about this, but I also don't really
>> understand why it's important for us to say it. But regardless, I
>> think this should be in brackets? It sounds like technical advice per
>> the preamble.
> Yes, I just failed to bracket it.
> I want to put this in because I'd like to be able to drop sysvinit in
> (its current form at least) in jessie+1, without duplicating or
> triplicating all the init system integration work.
> Putting this in here sends a signal that we would look favourably on
> some kind of compatibility layers. I don't think it's essential if
> people object to it.
Okay, that seems fine to me. It certainly seems harmless, and it would be
nice if we could get there.
>> This all seems nice in theory but rather problematic in practice.
>> [...] In other words, I don't think this should apply to, for
>> instance, use of FDO desktop files for menus instead of the Debian menu
>> system, since both can continue to work in parallel and neither takes
>> over from the other in a way that prevents the other from working.
> I don't agree. Unless we either have a compatibility shim, or a policy
> decision to transition, every package ought to be required to provide
> something in the Debian menus. Isn't this situation analogous to the
> mime-support argument where we required a package to reinstate a mime
> entry ?
Sorry, I didn't state my objection very well. I wasn't talking about
packages removing menu files.
Rather, your original wording to me sounds like introducing support for
desktop files in Debian would violate this guidance unless the one
introducing that support went through the Policy process first, even if
the new support did not conflict with menus and did not break anything
about menus. That seems wrong.
In other words, just introducing something that is intended as a
replacement for some existing Debian functionality should not require
coordinating with anyone. What requires coordination is the point at
which the new functionality starts breaking the old functionality, so that
the project as a whole can decide that either we need to do something else
or that the old functionality isn't important and it's fine to break it.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: