We have been asked to decide the default init system for jessie. As I have just said, my conclusion is that we should choose upstart.
However, we also need to decide whether we intend to allow users to choose otherwise. So we need to say what we expect of package maintainers in terms of support for other init system(s). It seems to me that the benefits of upstart integration are such that we should encourage transition to upstart jobs, subject to my concerns about the need for a new readiness protocol. I am not comfortable with the idea of /mandating/ use of upstart. We may discover that despite our adoption, upstart loses the war, or we may find that we want to switch to openrc or another contender. And, given the strong opinions on this topic, I think it is at the very least premature to tell our users and downstreams that they are on their own if they want to use systemd. At the moment, there is no meaningful compatibility layer between all these systems other than sysvinit scripts. This is unfortunate, but given the current state of development of both systems I think this is to be expected. So I'm sorry to say that I think we need to continue to maintain sysvinit scripts in jessie. The alternative would be to permit a package to drop sysvinit support if both systemd and upstart configuration were provided, but I'm not happy at this stage to burn our bridges like that. It would be worth researching some kind of compatibility options. Perhaps simple daemons with very formulaic upstart job files could have synthetic systemd units created. Or something. I think we should give package maintainers some guidance on what kinds of upstart or systemd patches should be accepted. Without this, it's likely we'll find ourselves adjudicating disputes that ought to have been settled in principle much earlier. I think that patches for either should: - use a non-forking startup method - avoid significant amounts of open-coded AF_UNIX socketry - avoid embedded copies of daemon library code - avoid extra build-dependencies (eg on libsystemd) - avoid extra runtime dependencies (eg on deb-systemd-helper) (If the current state of the art in readiness protocols persists that means that upstart patches using raise(SIGSTOP) ought to be accepted, but systemd ones rejected unless they can use socket activation.) We should recommend: - daemon authors and Debian maintainers should prefer command-line options to environment variables - whatever environment variables and fds are used, measures should be taken to avoid them being inherited by daemons' arbitrary children IMO we should treat native non-forking upstart support as we have in the past done for release goals, ie with a low threshold NMU policy of some kind. But as I say I would like to see us try to get agreement or near-agreement on an improved startup protocol. I would suggest that we allow (say) a month for this process, starting now. Before this is settled we shouldn't go around converting a whole bunch of daemons. And, there are two loose ends about systemd in particular: - There doesn't seem to be any Debian policy about how to provide systemd units in Debian; - systemd upstream and the Debian maintainers like to put much of the configuration in /lib; this is controversial and someone needs to decide whether this is appropriate. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
