Colin Watson <cjwat...@debian.org> writes: > I'm currently undecided about whether I prefer the approach of setting > technical policy under 6.1.1 or offering advice under 6.1.5. Bearing in > mind all the process discussions we've had, I can see that it might be > better to take the approach of offering technical advice rather than > getting (re-)embroiled in a distracting procedural dispute about whether > the Constitution entitles us to rule in advance on a subject that hasn't > clearly been asked of us by some other first-responding maintainer.
I also think Keith's point that the normal process for setting Policy can probably handle this is entirely correct. Certainly, I don't think there will be substantial difficulties hammering out a Policy change given advice from the TC. If there is, we can always deal with it at that point. > To start with, I therefore propose the following amendment to L. I > think it is no weaker except in ways that we would agree were in fact OK > if we found ourselves needing to rule on them specifically, and this > addresses points that people have raised here. The first paragraph of > the "loose coupling" section is replaced by the following: > In general, software may not require a specific init system to be pid > 1, although degraded operation is tolerable. The exceptions to this > are as follows: > * alternative init system implementations > * special-use packages such as managers for init systems > * cooperating groups of packages intended for use with specific init > systems > provided that these are not themselves required by other software > whose main purpose is not the operation of a specific init system. > Maintainers are encouraged to accept technically sound patches > to enable improved interoperation with various init systems. There's probably no chance that I will vote any version of L above FD, so feel free to disregard this. But I think this is begging for some sort of definition of "specific." As written, it seems like it either requires all packages in the archive add runit configuration, since otherwise they're not supporting all init systems available in Debian, or alternately that any package that provides a runit configuration and an OpenRC configuration and depends on runit | openrc is fine, since it doesn't depend on "a" specific init system (it depends on one of two specific init systems). I don't think either of those are what you intend here. But I'm at a loss as to what you *do* intend. Explain it to me like I'm five? :) >> For the jessie release, all packages that currently support being run >> under sysvinit should continue to support sysvinit unless there is no >> technically feasible way to do so. "packages" here should probably actually be "software" for all the reasons discussed elsewhere. > "Technically feasible" is so dependent on interpretation that I'm not > sure whether it has enough real meaning. My instinct is to borrow some > of the "exceptional cases" language from an earlier paragraph. On the > other hand, "all packages that currently support being run under > sysvinit" seems to mostly cover this well enough - it just takes me a > couple of readings to get to it. Does this sentence bother anyone else? > Russ, can you give an example of a package that currently supports > sysvinit where you would be happy that it might stop supporting it for > jessie due to a lack of technical feasibility? Yes: logind. I think it should be fine to package a current version of logind for Debian (meaning one that requires cgroups). I don't think logind is part of the init system implementation; it's just another program, like udev, that's built from the systemd source package. I don't think it falls into any of the other exception cases. I think it's quite reasonable to package a current logind for those who want to use it, even though, by requiring cgroups, it currently only works with a corresponding version of systemd as init. (Note that packaging it and having other packages depend on it are distinct acts with separate implications.) My understanding of the expected situation for jessie is that either another cgroups implementation that works under sysvinit will be available or someone will package logind 204 in a way that works with sysvinit. Given that, it will be technically feasible for GNOME to depend on a logind solution that doesn't require systemd. Therefore, this advice says that GNOME should not depend on systemd as init. (This is all totally obvious, of course, and I'm quite confident that the GNOME maintainers don't need this advice to do the right thing, which is exactly why I will probably be voting Keith's proposal first.) But suppose that the alternative cgroups implementation doesn't materialize. That specific logind implementation then *would* depend on systemd as init. Does that mean that a logind that uses systemd cgroups management is not permitted in Debian for the jessie release even if another version of logind is also available? Without the technically feasible qualification, this would be against our advice since the current packaged logind doesn't require systemd as the init system, and I see no reason for it to be. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txc2tkk2....@windlord.stanford.edu