Re: Package tool with systemd dependency

[Jan Luca Naumann <j.naumann@fu-berlin.de>]

Hey Simon and Ansgar,

thank you for your help and input. I think I will use the dependencies
that Simon uses for dbus-user-session.

Best regards,
Jan

Am 21.06.2016 um 14:39 schrieb Simon McVittie:
> 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
>