Hi, Michael Stapelberg <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
