Followup-For: Bug #1035543
X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de,
jspri...@debian.org, ans...@debian.org, a...@debian.org,
debian.bugrep...@wodny.org
I've been 'approximately' testing this locally on bookworm by:
* Editing the Install.WantedBy in /lib/systemd/system/e2scrub_reap.service
* Reconfiguring the package using 'dpkg-reconfigure e2fsprogs'
(I know, it's not a comprehensive workflow - but I think that it calls the
relevant deb-systemd-helper and e2fsprogs postinst script sections)
Also: Marcin's patch[1] from #985787 is also intended to fix a very similar
problem (perhaps exactly the same issue).
Some puzzles:
* Why does the 'deb-systemd-helper disable' invocation not work (as found
by Helmut and Jochen)? It seems like it should read the symlink path to
remove from the dsh-also state file, so the Install.WantedBy change should
not affect it.
* Is the /var/lib/systemd/deb-systemd-helper-enabled/ path relevant? This
seems to contain a shadow copy of much of the /etc/systemd/system service
state.
* Is the 'create links unless no links installed' logic correct? (that
sounds like it could be incorrect, but I'm not sure)
I did manage to get something kinda-working locally with a combination of an
'update-state' call and Marcin's patch. However, I'd like to understand more
about the 'deb-systemd-helper disable' call failure before recommending that.
And, quoting Andreas:
> Actually the difference is between the minimal bullseye chroot upgraded
> to bookworm and the bullseye chroot with some packages to be tested
> installed (here: systemd) and upgraded to bookworm. Ideally, after
> removing the packages to be tested and their dependencies, the two
> bookworm chroots should be identical ...
I agree on the goals there. Being unhappy about systemd and maintaining a
package that has divergent on-filesystem results depending on how users
upgraded seems distinctly worse than being unhappy about systemd while
maintaining a consistently-deployed package.
[1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985787#25
[2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035543#62
