Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[Michael Biebl]

The title of this bug report is highly misleading.

Let's see what's actually happening here:


bullseye chroot:
# find /etc/systemd/system/ -name e2scrub_reap.service
/etc/systemd/system/default.target.wants/e2scrub_reap.service

bookworm chroot:
# find /etc/systemd/system/ -name e2scrub_reap.service
/etc/systemd/system/multi-user.target.wants/e2scrub_reap.service

bullseye chroot upgraded to bookworm:
# find /etc/systemd/system/ -name e2scrub_reap.service
/etc/systemd/system/multi-user.target.wants/e2scrub_reap.service
/etc/systemd/system/default.target.wants/e2scrub_reap.service







So what I would suggest is a
if dpkg --compare-versions "$2" lt "$ver of your next upload"; then
  rm -f /etc/systemd/system/default.target.wants/e2scrub_reap.service
fi
in your postinst to clean up the stray enablement symlink.

Michael

So, you have the service enabled both in default.target and multi-user.target. Does this pose any actual problem? Not really. It is properly started during boot and if you purge the package, both symlinks are removed. It is thus imho not a serious issue, but something you might want to fix at it is a bit confusing. That said, I find the piuparts output not very readable, so there might be another issue I don't see. In this case, Andreas needs to clarify the RC status of this bug.

OpenPGP_signature
Description: OpenPGP digital signature