Re: systemd-fsck?
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/
slangasek@ubuntu.com vorlon@debian.org
Reply to: