Dear Maintainer,

if a package in version 1 had WantedBy=a.target and this is changed
to WantedBy=b.target in version 2 of that package, deb-systemd-helper
will properly create the links in b.target.wants/, but will not remove
the links in a.target.wants/. Same goes with changes in Alias= and
changes in Also=.

I've attached a patch to this bug report that fixes this.

Note that any additional links that were manually created by the
administrator will not be touched, only those that were created by
deb-systemd-helper in the first place. The only use case that is
not covered by this patch is if an administrator wanted to keep a
link that was auto-created (there is no way to distinguish them),
but that seems to be quite unlikely (and the administrator could
re-create it later - and it would then stay, even if the same
version of the package were to be installed again - only upgrades
will remove links).

I've also attached a trivial package in two versions to test this.
They change all 3 options (WantedBy=, Also= and Alias=) to test
everything at the same time. Just extract the source tarballs and
build the native packages if you want to test this.

Please change the commit message of the patch so that it reflects
the bug number it closes when you apply it to git.

Regards,
Christian

The test packages only have test-changes.service differ, the other 2
are the same in both versions...

But I checked that the link is removed if it was existing, a new one I
created is preserved, and if I remove an enable link, then the
disabled state is preserved to the new name (ie, when moving from
targetA to targetB if I disable in targetA then it won't be enabled in
targetB).

However, (and I don't know if this is new or not), the state does not
seem to be removed on package purge: I removed a target, purged the
package, then reinstalled the package and the enable link was not
generated.

Yes, sure. But the original service changes all three settings - so
I can see that all of them are affected. I only include the two
services to make sure I can change Also=, otherwise I wouldn't have
included them.

:-)

That shouldn't happen. I've just tried in a Jessie VM to just
install testpkg_42, remove one of the WantedBy= links, purge it,
install it again - and then everything was recreated as expected.
On the other hand, I don't remember what you're describing while
I was testing this, so I'll look into it and try to reproduce
(and if I can, fix it). I'll probably get back to you tomorrow
on that, since I'm a bit busy today.

Christian

FWIW, I tried to test what happens if a service has more than one
WantedBy target, and only one of those was removed by the admin, and
the new package uses a different 2 targets.

Now I need to clean up manually in order to do more tests

Hello,

I have tested the patch proposed in this bug and it doesn't work for me.

It does indeed remove the old WantedBy= link, but doesn't create the new one and
the two lines (old & new) remain in the dsh_state file.

Without the patch, the two lines are present in the dsh_state file, but the
second one is never created since in enable() :

no_link_installed() will return false for the second entry in the dsh_state
file, which is the link to be created for the modified WantedBy=

HTH,

Kind regards,

...Louis