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

Re: Package tool with systemd dependency

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

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.


[*] 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

Reply to: