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

Michael Stapelberg stapelberg at debian.org
Wed Jul 24 20:01:42 BST 2013


Hi,

Michael Stapelberg <stapelberg at debian.org> writes:
> 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).
Status update: This is all implemented, see
http://anonscm.debian.org/gitweb/?p=collab-maint/init-system-helpers.git;a=summary

I will run the following manual tests in addition to the test suite now:

Build three packages:

p1 1.0-1 ships one service file which is enabled by default.
p1 1.0-2 ships the same service file, but with Alias=foo.service.

p2 1.0-1 ships one service file which is disabled by default.
p2 1.0-2 ships the same service file, but with Alias=foo.service.

p3 1.0-1 ships two service files, both enabled by default.
p3 1.0-2 drops one of the service files.

Test steps:

1) Install p1 1.0-1, verify the state file gets created and contains the
   service file. Verify the service file is enabled.
2) Upgrade to p1 1.0-2, verify the state file gets updated and the alias
   gets created.
3) Purge p1, verify the state file gets deleted and the service file and
   alias symlinks get deleted.

4) Repeat 1, 2, 3, but disable the service after 1 and ensure it does
   not get re-enabled after 2.

5) Install p2 1.0-1, verify the state file gets created but the service
   file is not enabled.
6) Upgrade to p2 1.0-2, verify the state file gets updated, the service
   is still not enabled and the alias was created.
7) Purge p2, verify the state file gets deleted and the alias gets
   deleted.

8) Repeat 5, 6, 7, but enable the service after 5 and ensure it stays
   enabled after 6 and gets disabled after 7.

9) Install p3 1.0-1, verify the state file gets created and both service
   files are in the state file and enabled.
10) Upgrade to p3 1.0-2, verify the state file does not contain the
    dropped file anymore and the dropped file’s symlink is deleted.

11) Repeat 9, 10, but disable the to-be-dropped service file after 9 and
    verify it still gets removed from the state file.

Let me know if I missed a test case.

-- 
Best regards,
Michael




More information about the Pkg-systemd-maintainers mailing list