Bug#727708: init system discussion status
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Sure. I borrowed your text and edited it slightly for clarity. I also
> changed "upstart/systemd" to "upstart", for two reasons: one is that at
> this stage I'd prefer to try to maintain only one version of this text.
Yeah, that's fine. We can hammer out the details of one path, and then
figure out whether it makes sense to have the systemd path be a completely
separate writeup or whether it should be presented in the form of an
amendment.
> And the other is that IMO the proposed prescription for non-Linux ports
> doesn't make sense for systemd. There is little prospect of systemd
> being "ported" to those systems.
I'd prefer to leave it in. Upstream's opinions aside, systemd is free
software and if someone wants to try to port it (or, possibly more likely,
"port" it by writing something native that provides the same interfaces),
they can. Maybe upstream is right and it's untenable; maybe they're wrong
and it's not as hard as they think. I realize it's horribly unlikely for
jessie, but still, as a matter of principle, I'd rather encourage the same
software or at least the same interfaces across all of our ports.
But, anyway, we can focus on the upstart position first and deal with that
later.
> I've written a version of Niklaus's rule about dependencies:
> Likewise, packages must not Depend on or Recommend (directly or
> indirectly) a specific init(1). Violations of this are also an RC
> bug in jessie.
> And:
> Theses rules do not apply to machinery which itself forms part of
> the implementation of one or more init systems.
> That seems to be the clearest way to put the matter.
This seems fine to me, at least for right now. I'm doing a bit of
additional research right now to be sure that I understand the
implications of this and may end up asking for any problems that anyone is
aware of with this approach, just to be sure we're not missing something.
>> I think Policy 4.13 already covers this adequately and we don't need to
>> say anything further in the decision.
> I would like to be clear that maintainers don't need to take patches
> that introduce embedded copies of sd_notify.
Oh, okay. I had missed that aspect of things. I think it's fine to be
clear about that as long as we're not prohibiting via non-advice TC
decision using an embedded copy (which feels like bug severity inflation
to me).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: