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

[Michael Stapelberg]

Hi Michael,

Michael Biebl <biebl at debian.org> writes:
> There might not only be changes to the [Install] section, but also the
> case, where a package stop shipping a .service file and where we need to
> clean up the existing symlinks during the upgrade process.
Yes. When a package entirely drops a service file, the maintainer will
need to add an explicit deb-systemd-helper disable call for that service
file to get the symlinks cleaned up. This call should be done while
setting _DEB_SYSTEMD_HELPER_PURGE=1 to also get rid of the state file
_for that service file_, e.g. removed.service.dsh-also.

Furthermore, references to this file need to be removed from other state
files, too. See below for the update-state command. A subtlety here is
that unit files of other packages (!), say third-party.service, might
use Also=removed.service, which will then not get cleaned up in
third-party.service.dsh-also. Not only for this reason we should
discourage people from using Also= across package boundaries. A lintian
check would be good. Do you agree? If so, I’ll file a wishlist bug.

> This case is similar, but not quite the same. In the case of the changed
> [Install] section, we should try to preserve the enabled/disabled state
> on upgrades. In case of the removal of the file, that is not an issue.
Agreed.

My current strategy is as follows:

1. Implement was-enabled, as explained in #17.
2. Implement debian-installed, a command which will return whether this
   service file has ever been installed, i.e. touched by
   deb-systemd-helper, or whether it is a new file.
3. For every service file, in the postinst script, do:

   3.1) In case the package uses dh_systemd_enable
        (i.e. enable by default):
      On new installations, run deb-systemd-helper enable.

      On upgrades, run deb-systemd-helper enable if was-enabled¹. This
      will create new symlinks, if any, and update the state file.

      On upgrades, run deb-systemd-helper update-state if
      !was-enabled. This will update the state file only.

   3.2) In case the package uses dh_systemd_enable --no-enable
        (i.e. disable by default)
     On new installations and upgrades, run deb-systemd-helper
     update-state (so the state file is up to date on purge, which is
     necessary if the user enabled the service file(s) manually).

     On upgrades, if the service file was-enabled, run
     deb-systemd-helper enable to create new symlinks, if any.

4. The update-state command will also remove symlinks from the state
   file that are no longer relevant (I will design a test case
   for this to make sure it doesn’t break anything).

① Note that this fixes a bug we currently have: at the moment we run
  enable unconditionally, so even if the user disabled the service, if
  new symlinks are added, they will get created.

-- 
Best regards,
Michael