On 13/02/2026 19:29, Niels Thykier wrote:
Control: tags -1 moreinfo
On Fri, 13 Feb 2026 18:49:41 +0100 Alessandro Astone
<[email protected]> wrote:
Package: debhelper
Version: 13.24.2ubuntu1
Severity: normal
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.
[...]
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.
