On Mon, Jan 20, 2014 at 08:27:47AM +0100, Tollef Fog Heen wrote: > > GNOME certainly uses these interfaces already. Whether they should be > > considered a "dependency" or not is probably something that should be left > > to the maintainers' discretion. But I think they should certainly be > > handled the same way as logind, generally - with a dependency on some > > virtual package that other implementations could provide (or that can be > > provided by a binary package from systemd source that doesn't depend on pid > > 1 - since these dbus services all work fine on non-systemd systems, and > > there's no technical reason that should ever change given the function of > > the services in question). > I'm willing to look at adding virtual packages for those once we > actually see alternative implementations happening. Adding them because > somebody might, maybe, possibly add them somewhere down the line sounds > premature. Well, I don't agree that it's premature at all. We're talking about very distinct sets of interfaces being exposed (dbus services vs. init system interfaces), and conflating them under a single package name (...and upstream project name) is IMHO the root of all the upset around GNOME and systemd at the moment. Providing these virtual packages may seem frivolous while there's only a single implementor, but it makes it very clear to all developers that the systemd and GNOME maintainers have done their part to accomodate alternatives... and that if alternative implementations do not emerge, people who are unhappy with this have no one but themselves to blame. In that sense, I think it's a useful technique for forestalling future flamewars, even if it's *technically* easy to make this change at some future point. > As for whether they should work with non-pid1 or not, it's also a > question about what we (the systemd maintainers) want to support. The > daemons currently don't require systemd as pid1, but given all the flak > over maybe making logind require systemd as pid1 there is a very strong > incentive to not make those implementations work with another init. The > CTTE here and in the past (see NM) views regressions as much more > serious than lacking implementations. > I think this is pretty sad and gives maintainers perverse incentives, > since there's not really any graceful way to say «this will no longer > be/is no longer supported» without risking being struck down. It's a > somewhat separate discussion from the whole «what should be the default > init system» discussion, but it's one we (as a project) should be having > at some point. Speaking for myself, I don't think it's the systemd maintainers' responsibility to make logind work on non-systemd systems, but that it is your responsibility to communicate with the project (or maintainers of related packages such as systemd-shim) about upcoming changes that would introduce regressions and make a reasonable effort to coordinate updates so that the maintainers of those related packages have an opportunity to respond. For instance: to date we've discussed the bump to v205 in Debian in rather fuzzy terms. Is there a specific deadline by which you think this needs to be taken into Debian (either to ensure it's stabilized for the jessie release, or in response to requirements from reverse dependencies)? Work on cgmanager+systemd-shim is progressing, but it would be best to know when it needs to be available in Debian in order to unblock you for systemd v205. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature