Steve Langasek <vor...@debian.org> writes: > And so I am greatly dismayed by the position Russ and Bdale have taken > in this discussion with respect to packages being allowed to depend on a > specific init system. Both have expressed the opinion that Debian > should remain open to alternative init implementations as long as there > are developers willing to do the work; but when it comes to concrete > examples of ways in which conflation between init system (that is, > service registration and service management) interfaces and dbus service > interfaces directly interfere with that goal, they have been unwilling > to stand up for the relevant technical principle.
You can be dismayed all you want, but I completely disagree with you about the shape of the relevant principle. There is a huge difference between being open to alternative init implementations and requiring that maintainers implement support for alternative init systems, which is what the loose coupling option requires. The latter is, in my opinion, effectively an attempt to coerce maintainers into doing work they don't want to do by holding their packages hostage, which is something that I think we should only do for things that are absolutely vital to the project. And I don't believe this is. What I want to see is people working with the relevant maintainers, understanding their concerns and issues, and find a way to provide maintainable support, not just asking the Technical Committee to force other people to change how they maintain their packages well in advance of actual irresolvable impasses. And when no one has done the work to port a particular package to another init system, preventing that current reality from being properly represented in dependencies just makes the distribution more technically fragile without any real gain for our users. > This despite the fact that the burden on the GNOME maintainers to > support alternate implementations of these dbus services is much lower > than the burden of providing sysvinit startup compatibility in jessie > for an upstream project that doesn't support it. The reason why requiring sysvinit startup compatibility makes sense to me is because everything in the archive *already* has sysvinit startup capability, and therefore what we're asking for is for maintainers to sustain the status quo through jessie as much as possible so that we can manage an orderly upgrade. I certainly hope that we're not going to have to maintain sysvinit scripts indefinitely. > As Philipp Kern points out in > <41b26b373019ab39ebff223603a08...@hub.kern.lc>, this leaves us with the > very real possibility that we will wind up with mutually incompatible > sets of packages in the archive for jessie that are no longer > coinstallable, not because the packages themselves have conflicting > functionality, but because they've taken sides - intentionally or > unintentionally - on the init system question. If we don't think such > fragmentation of the Debian archive is an acceptable outcome (and I for > one don't see any reason it should be), then we should say as much in > our resolution. The committee has a duty to provide strong technical > guidance to the project, not just to get involved after something has > gone off the rails. If you want to explicitly say that packages are required to support the default init system, then you should propose language. That's not what the loose coupling option says. The loose coupling option says that all packages must support *all* init systems, with some possible degredation of operation. I believe that effectively locks us into supporting sysvinit scripts forever, since no alternative universal common denominator seems to be emerging. -- 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
