Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > 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 These all seem reasonable to me, with the caveat that if *upstream* includes open-coded AF_UNIX socketry or embedded copies of daemon library code, I don't see any need for Debian package maintainers to remove that code. > - avoid extra build-dependencies (eg on libsystemd) > - avoid extra runtime dependencies (eg on deb-systemd-helper) These requirements, on the other hand, I find completely baffling. This approach seems completely contrary to Debian best practices. Our standard practice with all packages is to fully enable all available features that make sense on Debian and don't pose some concrete risk. This means that, for example, I have CUPS libraries on this system despite the fact that I never print, Avahi libraries depsite the fact that I will never use that software, and SELinux libraries deeply embedded in core code despite the fact that few Debian systems currently run SELinux. These requirements seem like would fit with Gentoo, where much emphasis is placed on letting people build custom-crafted binaries to their local requirements, not Debian's approach of providing a full-featured and uniform distribution. Needless to say, I don't think we should avoid dependencies on libsystemd-daemon or init-system-helpers, and I think it would be wholly inappropriate for the Technical Committee to say anything of the sort. > (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.) So, as mentioned above, I don't agree with this, although of course I think using socket activation is, in general, better than using the readiness protocol. > We should recommend: > - daemon authors and Debian maintainers should prefer command-line > options to environment variables I disagree with including this in a statement. I think it's outside the scope of what we were asked to resolve, and I don't think it's the place of the TC to offer this sort of general advise to upstreams. > - whatever environment variables and fds are used, measures should be > taken to avoid them being inherited by daemons' arbitrary children I agree with this as good practice for daemons, but again, I don't think it's the role of the TC to issue this sort of general advice that is not directly related to a question put before us. If we're going to offer specific advice, we should limit it to the specific integrations that we're asked to consider. But I think we should be mindful of the restriction on the TC not doing design work and let Policy for packaging support of upstart and/or systemd be hashed out through the regular Policy process. -- 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
