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

Re: Package tool with systemd dependency



On Tue, 21 Jun 2016 at 13:49:27 +0200, Ansgar Burchardt wrote:
> The upstream repository looks like it provides .service units for a
> "systemd --user" instance.

Lots of projects do this; if combined with other ways to start the
service (such as D-Bus activation), it certainly doesn't merit a
hard dependency on systemd-sysv.

(I have no opinion on whether profile-sync-daemon should enforce use of
"systemd --user" or not; that's a social rather than technical question,
based on what its upstream and its Debian maintainer are willing to take
responsibility for.)

> It should be fine to only provide a unit for "systemd --user" 
> and people who don't use systemd or libpam-systemd then have to
> configure the service start and stop themselves.

Yes up to a point, but not if the "systemd --user" integration is
considered to be critical to the specific binary package with the
dependency. If you want a D-Bus session without having a systemd --user
instance, you can install dbus-x11 and use dbus-launch, or you can install
dbus and use dbus-run-session; but you shouldn't install dbus-user-session
and expect it to work without systemd --user, because integration with
systemd --user is the only thing that dbus-user-session does.

If dbus-user-session had the same semantics as traditional D-Bus
in terms of what a "session" means, I'd have just included it in
dbus with a Suggests on libpam-systemd, but since it isn't 100%
compatible, it's a separate package to provide a way to make the newer
semantics opt-in. Until/unless someone provides a working non-systemd
implementation, it can only do what its documentation says it does by
using systemd --user.

dbus-user-session does have Depends: libpam-systemd and Recommends:
systemd-sysv instead of two hard dependencies, but only to account for
the possibility of starting systemd via init=/lib/systemd/systemd.

    S


Reply to: