To bring it back to the package at hand, because talking about
abstractions isn't helpful here IMHO:
On 06/21/2016 02:39 PM, Simon McVittie wrote:
> On Tue, 21 Jun 2016 at 13:49:27 +0200, Ansgar Burchardt wrote:
>> 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.
Well, in this case it's rather simple, the units of the software in
question have the following effect [*]:
- at login a certain command is executed
(profile-sync-daemon resync)
- from then on the same command is executed every hour
- at logout a different command is executed
(profile-sync-daemon unsync)
Plus the dependencies of the user units are done in such a way that
only ever one of these commands is executed at the same time.
So what happens here is that profile-sync-daemon is not actually a
daemon, but rather a command that is executed periodically to
perform a specific action.
Off the top of my head, especially considering the guarantee of
only ever executing one of these commands at a time, I don't know
of anything out of the box that could do that on non-systemd
systems.
That said, it should really not be difficult to write some simple
program that runs in the background, properly handles X11 session
termination (i.e. recognizes it and performs actions), and then
executes the commands in the same fashion. (And hook that up via
/etc/X11/Xsession.d, with a check to disable it if systemd is
running, because there you wouldn't need it.)
So I think the systemd dependency here is just because the author
of the upstream software didn't actually want to write a long
running program, and used systemd's features to have an action
take place repeatedly.
So I see three options for the packager of this software:
a) Declare a systemd-sysv + libpam-systemd dependency for now.
b) Don't explicitly declare the systemd-sysv dependency (but do
depend on libpam-systemd, so that user sessions are enabled
on systemd systems), and mention in either README.Debian or
so that people will have to figure out on their own how to
start it if they don't run systemd. (I would suspect that
the program itself doesn't really require systemd, just
from looking at my analysis of the units.)
c) Create the solution for running this on non-systemd systems
yourself. (This would be more work though.)
In my personal opinion, b) and c) seem more reasonable to me
than a), because while b) doesn't offer Debian's "runs out of
the box" experience on non-systemd systems, it at least allows
people to install the software and figure it out for themselves.
Regards,
Christian
[*] Technically, since systemd user instances aren't directly
tied to sessions, the semantics are actually slightly
different, in that login only means the first login, i.e.
separate parallel logins e.g. via SSH (while the initial
session is still active) don't have any effect, but the
"logout" action will only be taken once there are no more
sessions of a given user at a given time. (Even if the
remaining session wasn't graphical.) Also, if the user
enables logind's lingering, this will change semantics
again. But on a typical desktop system (for which this is
intended), where one logs in graphically and only once,
the login/logout semantics I mentioned do apply.
Attachment:
signature.asc
Description: OpenPGP digital signature