Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > As I mentioned on IRC, I think we need to get some clear answers to > certain questions from everybody.
> * For which init systems should there be a low nmu threshold for > native support in packages ? I believe this should be the Linux default plus (if different) whatever init system is used by the non-Linux ports. (Putting aside the question of whether the Technical Committee can set an NMU threshold for the moment.) > * Daemon package maintainers should accept reasonable patches for > some set of init systems. Which init systems ? The same as the list for a low NMU threshold above. > * What opinions do we state for jessie+1 - are we hoping for one or > two systems (which two), or more, or are we not saying yet ? I think we should say that native (not via legacy sysvinit shell scripts) support for the Linux default is encouraged for jessie+1, and beyond that leave this alone. My fallback position would be to say that we expect to converge on at most two well-supported init systems, one for Linux ports and one for non-Linux ports. I think the question of whether to use OpenRC or upstart for non-Linux ports is best deferred. > * If systemd is the default on Linux, what opinions do we want to > state, if any, re non-Linux ports at this stage ? We will require sysvinit support through the jessie release. Post jessie, my preference would be to say that support for the init system used by non-Linux ports should be treated the same way as any other porting issue to the non-Linux ports, such as PATH_MAX issues with Hurd. In other words, those are normal bugs in packages unless the release team decides that a non-Linux port is a release architecture, maintainers should apply patches unless they're excessively intrusive, and maintainers aren't expected to test on those architectures. > * What should be an RC bug in jessie ? > * What should be an RC bug in jessie+1 ? I think we should (and possibly are required to) defer to the release team on RC bugs in particular, but I do think we should say that support for the default init system and for sysvinit are required for jessie (with the caveat about what "required" means for packages that rely on functionality not provided by sysvinit). > I also think we need to answer: > * What level of dysfunction is OK if an application (or a desktop > environment or whatever) isn't running on its preferred pid 1 ? I think this depends a lot on whether the package is something significant enough that we would consider it to be a release blocker or whether it is an edge package, and whether the package is directly related to the init system or is unrelated. For example, were someone to want to package a variety of neat daemon management tools for OpenRC, I don't see any reason why that should be prohibited from the archive even if it requires OpenRC to run. And while I think it's a little weird to have some application in the archive that's packaged so that it will only work with a non-default init, as long as it declares that dependency in some reasonable way (that doesn't result in the system being switched to that init system when it's installed), I have a hard time seeing exactly what it *hurts* to have it in the archive. I think that major packages that would be considered release blockers, which probably includes GNOME, KDE, and Xfce, need to support the default Linux init system in the sense that, if they don't, I don't think we can release. I think a substantial degredation of functionality when running on an init system other than the Linux default would be okay for for jessie+1. For jessie, I think it depends greatly on how feasible making them work with sysvinit is (and I suspect sysvinit support would be sufficient for all other purposes). > * Do we want to give any guidance about what a maintainer may consider > an unreasonable native-init-system-support patch ? Or to put it > another way, do we intend to overrule a maintainer who declines to > implement one (or any) non-forking startup protocol ? This is hard. I'm not sure. I'm leaning towards not getting into this. -- 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
