[Pkg-systemd-maintainers] Bug#717603: Bug#717603: How to handle service files, where [Install] has changed

[Michael Stapelberg]

Hi,

Michael Stapelberg <stapelberg at debian.org> writes:
> 1) If the [Install] section changes, deb-systemd-enable needs to update
>    its state file, so that it can remove all symlinks on purge.
>
> 2) As you mentioned, we also need to create all not-yet-created
>    symlinks.
>
>    Right now, I think this requires a new command, since
>    deb-systemd-helper is-enabled will most likely not return true after
>    the changed service file is present, so the naive
>    deb-systemd-helper is-enabled && deb-systemd-helper reenable
>    is not enough.
My current idea is to introduce a command called “was-enabled”, which
will only consider the links saved in the state file, i.e. from the old
unit file.

This solves both issues in this way:

In case the service was enabled before installing the new unit file
(“was-enabled” returns 0), we simply run “enable”, which will (right
now!) create the new symlinks, so issue 2 is fixed. Furthermore, it will
update the state file when creating the new symlink, so issue 1 is
fixed, too.

In case the service was disabled by the sysadmin before installing the
new unit file (“was-enabled” returns non-zero), we run “enable --quiet”
followed by “disable --quiet”, which will update the state file, but
only have the enabled symlink for a brief period of time. This is the
same way dh_systemd_enable’s “--no-enable” works. We should also
implement “--no-reload” (as upstream systemctl does) to not reload after
making any changes so that we don’t potentially suffer from race
conditions during package upgrades.

> This seems like a good point to add a testsuite to i-s-h, to ensure we
> don’t break what we currently have when adding that feature.
This is done, see
http://anonscm.debian.org/gitweb/?p=collab-maint/init-system-helpers.git;a=tree;f=t

-- 
Best regards,
Michael