On Mon, May 12, 2014 at 04:21:56PM -0700, Josh Triplett wrote: > > > Consider a system which has systemd installed, systemd-sysv *not* > > > installed, and systemd used as PID 1 via init=/bin/systemd. Since > > > systemd-sysv is not already installed, "systemd-shim | systemd-sysv" will > > > pull in systemd-shim instead, which will atttempt to supply services that > > > conflict with systemd's.
> > systemd-shim is bus-activated-only. The dbus name will already be claimed > > by systemd itself on startup, so systemd-shim will be a no-op on such a > > system. > I appreciate the clarification; thanks. > In that case, as one possible option, given that systemd-shim exists "to > run the systemd helpers", which the systemd package provides (logind, > etc), how crazy would it be for systemd-shim to depend on systemd rather > than providing its own (currently binary-identical) copy of > /etc/dbus-1/system.d/org.freedesktop.systemd1.conf? If it did so, then > there should be approximately zero danger of the two conflicting in any > way, and it should be zero risk to have the two coexisting on the same > system. > (I realize that that inverts the dependency relationship a bit, but > nonetheless it seems potentially sensible for maintainability and > risk-reduction.) Such a dependency probably wouldn't be terribly harmful, but it does seem to me that it would be a hack. Since the main impact of the duplication is that systemd-shim has to be updated each time the systemd dbus security policy changes, I prefer to wait and see whether this becomes a problem in practice (in terms of either maintenance overhead, or impact to users). > I'd still argue that "systemd-sysv | systemd-shim" is the right way > around, but nonetheless the above seems helpful from the point of view > of making sure sysvinit-core+systemd-shim and systemd can coexist on the > same system to allow runtime selection. It's not the right way around until we've decided that we're ready to make the switch to systemd as default, which is a decision that should be made collectively, and not as a result of libpam-systemd pulling it in automatically on some (desktop) systems while other systems continue with sysvinit. Even after making the switch to systemd by default in unstable, listing systemd-shim first arguably gives less surprising results to users who try to install a desktop environment on top of an existing system: if they've already picked up the dependency on systemd-sysv via sysvinit (once the default has been changed), then the dependency will be satisfied as-is; and if the user has deliberately avoided the selection of systemd-sysv, there's no technical reason that gdm3->libpam-systemd should be the thing that pulls it in. > > Stop spreading FUD. > Please consider assuming good faith; I appreciate you providing > a correction and participating in the discussion. Good faith doesn't enter into it. You made a claim, clearly not based on any first-hand knowledge, that the software didn't work. That's inappropriate regardless of any good intentions you might hold, and especially on a highly contentious topic like this one. -- 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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140513002643.gb32...@virgil.dodds.net
