Hi everyone Am 23.09.21 um 12:22 schrieb Ansgar:
Hi,On Thu, 2021-09-23 at 09:51 +0300, Martin-Éric Racine wrote:Setting up systemd (247.9-2) ... Removing obsolete conffile /etc/dhcp/dhclient-exit-hooks.d/timesyncd ... Removing obsolete conffile /etc/systemd/timesyncd.conf ... Setting up systemd-timesyncd (247.9-2) ...Someone wrote earlier[1] that this is caused by [2]. The timesyncd.conf file isn't intended to be removed. Ansgar [1]: https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2021-September/043059.html [2]: https://bugs.debian.org/994903
I've bumped the severity of this bug to serious and reassigned the issue to debhelper while keeping a clone assigned to systemd (#994931 , so it doesn't migrate to testing until a solution has been found).
I hope this is ok, Niels.
Afaics, this change in debhelper is what broke systemd/systemd-timesyncd
debhelper (13.5) unstable; urgency=medium
* dh_installdeb: Install debian/conffiles in compat 12+ again
(undoing the compat 12 change saying dh_installdeb would ignore
this file). The file can now be using for the activating the
`remove-on-upgrade` feature from dpkg 1.20.
* dh_installdeb: Automatically rewrite `rm_conffiles` into the
new `remove-on-upgrade` feature from dpkg when possible.
I need to go back a little: In systemd_245.4-2, we split off
systemd-timesyncd (along with its conffiles into a separate binary
package named systemd-timesyncd. The idea was to make it simpler to
install alternative time-daemon implementations. systemd now has a
Depends: systemd-timesyncd | time-daemon We have two use cases:a/ prior to the upgrade, no package providing time-daemon was installed -> we install systemd-timesyncd and transfer ownership of
/etc/dhcp/dhclient-exit-hooks.d/timesyncd /etc/systemd/timesyncd.conf to the new package during the upgrade.b/ an alternative, like ntp, is installed. In this case, we want to remove the now obsolete conffiles
/etc/dhcp/dhclient-exit-hooks.d/timesyncd /etc/systemd/timesyncd.conf from the systemd package during the upgrade. Unfortunately, dpkg has no native support for this scenario.So what we ended up doing is using Breaks/Replaces, rm_conffile and a bit of custom maintainer scripts code as can be seen in [1], where systemd-timesyncd.postinst, adopts the conffiles if they have been stashed away by dpkg-maintscript-helpers.
Obviously, we would have preferred a cleaner solution, maybe something that is directly handled by dpkg itself. But it's the best we could come up with and it worked ok so far.
Now, with the above change in debhelper, this code no longer works as intended. One issue I immediately see is that /var/lib/dpkg/info/systemd.conffiles doesn't contain any version constraints but only
remove-on-upgrade /etc/dhcp/dhclient-exit-hooks.d/timesyncd remove-on-upgrade /etc/systemd/timesyncd.confWhich I assume means, this code is run on every upgrade and as can be seen in this bug report, nuked the conffiles of the systemd-timesyncd package.
The question is, what can we do about this? A couple of thoughts a/ revert the change in debhelper b/ keep the change in debhelper but tie it to a compat bump, say version 14c/ add native support to dpkg (hi Guillem) to better allow for such a use case where a conffile is moved from one package to another. Update systemd to use that instead of the homegrown code.
Ideally, I'd prefer solution c/, but this needs time and work, so it's not something to fix the immediate breakage in systemd/systemd-timesyncd. So I guess we also need either a/ or b/.
Niels, what are your thoughts here? Or maybe there is another way to fix the immediate breakage?E.g. could "remove-on-upgrade" have a version constraint to it's only run when upgrading from versions older then 245.4-2?
Guillem, do you have any thoughts regarding c/? Is this something that could be implemented?
Regards, Michael[1] https://salsa.debian.org/systemd-team/systemd/-/commit/d6483013d5779d4d465a1e174e44a754b941d0e6
OpenPGP_signature
Description: OpenPGP digital signature
