Ian Jackson <ijack...@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 (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
