Dear Maintainer,

When enabling a service that specifies [Install] WantedBy=foo.target, a
symlink to this service is created at /etc/systemd/system/foo.target.wants/
On package upgrade, if the service file was changed to [Install]
WantedBy=bar.target, the symlink at
/etc/systemd/system/foo.target.wants/ is not removed and a new symlink
at /etc/systemd/system/bar.target.wants/ is not created

This may have serious consequences depending on the rest of the contents
of the unit file (e.g. it may trigger activation of other dependencies
when unwanted), or in the general case users will never see the effects
of the update.

Control: tags -1 moreinfo

Hi,

These symlinks are not directly generated by `dh_installsystemd`, so I
think you are looking for a different tool/component that needs fixing.
Probably the `deb-systemd-helper` command or something it invokes.

Best regards,
Niels

Traditionally, the symlink is created by `systemctl enable` and deleted
by `systemctl disable`.

 > deb-systemd-helper is a Debian-specific helper script which
 > re-implements the enable, disable, is-enabled and reenable commands
 > from systemctl

So assuming that deb-systemd-helper does the same, it all depends on how
deb-systemd-helper is invoked which makes me believe that it is
dh_installsystemd missing some logic, that is not calling enable/disable
appropriately. I do not see dh_installsystemd trying to call
`deb-systemd-helper disable` on upgrade.