[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Processed: block 726763 with 727708



On Sat, Feb 01, 2014 at 03:24:54PM -0800, Steve Langasek wrote:
> On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote:
> > The block added above simply reflects the many comments from GNOME folks
> > (and systemd folks for that matter) saying that they're waiting for the
> > fallout to clear before making any drastic changes.  Furthermore, it
> > reflects the reality of the current situation: you explicitly stated in
> > the bug log of 726763 that systemd-shim was not ready to serve as an
> > alternative to GNOME (though with different assumptions about how to
> > resolve that), and you furthermore objected to the suggestion of
> > resolving the situation by adding a recommends on systemd-sysv.  Thus, I
> > don't see any obvious action the gnome-settings-daemon maintainer could
> > take at this point to resolve 726763 without drawing ire.
> 
> Ok, it seems that wherever I sent my previous note about how I thought this
> should be fixed, it didn't actually manage to go to the bug log.  Sorry
> about that.

Thanks for that clarification.  That would explain why I hadn't seen
that mail when I reviewed the full bug log.

> While I think the Depends: systemd should be dropped (via a split of the
> systemd package), that's not required for fixing the present problem.  That
> can be addressed by having gnome-settings-daemon Depends: systemd,
> systemd-shim | systemd-sysv.

While that would DTRT for users with systemd-sysv installed, it will not
work for a majority of current systemd users in Debian, who use systemd
via just the "systemd" package and having init=/bin/systemd on the
kernel command line.  For such users, this change would attempt to
install systemd-shim, which should not happen on systems running
systemd.

Do you have a suggestion for how to solve that, given the constraints
of:

- not having systemd-shim conflict with systemd (since you've stated
  that you'd like to avoid that),
- not causing breakage in the systemd package, and
- not requiring systemd users to install systemd-sysv?

I can think of a few, but none that would be particularly simple to
implement or apply.

Adding "systemd-shim" as an alternative to the current dependency on
systemd could partially work, with the caveat that users who have
systemd installed but are not currently booted into it would experience
breakage.

As an aside, what is the list of interfaces systemd-shim provides?  I
previously had the impression that systemd-shim just provided the
systemd DBus interfaces that logind depended on, but did not provide
org.freedesktop.login1 directly, counting on a forked logind to provide
that on top of systemd-shim.  Are you saying systemd-shim provides
logind's interface directly, and thus satisfies GNOME's full dependency
needs already?

I'd also point out that there's no reason, other than the common issue
of init=/bin/systemd systems (which applies to both orderings) and the
current cloud of uncertainty surrounding init systems in Debian, that
that dependency couldn't also be written "systemd-sysv | systemd-shim".
Bug 727708 blocks one of the two alternatives but not the other, and I
see no reason not to consider both alternatives equally.

- Josh Triplett


Reply to: