Hi, On 2025-07-12 15:03, Helmut Grohne wrote: > Hello, > > On Wed, Jun 25, 2025 at 03:13:23PM +0200, Helmut Grohne wrote: > > I talked to Aurelien on IRC. This mail gives some context and summarizes > > our discussion. > > I worked out and tested a patch somewhat and I also talked to Paul and > Ivo. Summarizing results here. > > > The other side is what I discussed with Aurelien and much of what > > follows is due to him (thank you). systemd needs to be restarted when > > upgrading libc6, because it uses nss modules. Failing to do so results > > in e.g. #993821. The way to restart systemd has changed over time. For > > instance, restarting user managers and other daemons such as resolved > > has become a thing. Due to these changes, the responsibility of > > restarting was eventually transferred to systemd via means of a dpkg > > trigger (see #1074607) and the Breaks ensures that systemd can handle > > the trigger. The Breaks declaration shall ensure that systemd ends up > > being restarted, but what also does is require that systemd.postinst is > > run before libc6.postinst. We observe that we do not expect to bump the > > Breaks version in forky as it is an artifact of transitioning to dpkg > > triggers, so in later dist-upgrades the cycle at hand is expected to > > disappear. If we are trying to relax it, we'd have to re-add code for > > restarting systemd to libc6.postinst: > > > > if the installed systemd does not support triggers; then > > # Expect a bookworm systemd: > > # * If it were older, we'd be doing a skip upgrade. > > # * If it is newer (e.g. backports), it supports triggers. > > restart systemd the bookworm way > > # https://sources.debian.org/src/systemd/252.36-1~deb12u1/debian/systemd.postinst/#L77 > > fi > > > > I note that this is the code that Aurelien spent effort on to get > > removed from libc6 and moved into glibc. He expressed that he does not > > like this approach (for obvious reasons). > > I have prepared patch for glibc that drops the Breaks and adds he init > script. Tests performed: > * https://debusine.debian.net/debian/developers/work-request/103866/ > * Attempted to reproduce the problem with Breaks dropped, but I could > not reproduce it then. apt would simply upgrade libc6 earlier and not > do stupid things. > * Upgraded just libc6 in a VM (not container) and observed that systemd > would properly be restarted when expected. > > I hope that others agree with this level of testing striking a good > balance on effort and risk. > > Talking to the release team, Ivo and Paul were not super happy with the > maintainer script changes due to the risk involved in added code. They > pointed out that the lack of that addition would result in a risk of > people doing a partial upgrade (i.e. libc6, but not systemd) would not > get their systemd restarted. According to them, the scenario is quite > unlikely in a release upgrade and that people should not be doing > partial upgrades. If systemd is upgraded, it restarts itself. If libc > happens to be upgraded after systemd has done this restart, the trigger > added in trixie still will work. The one case the Breaks help is when > you upgrade libc6 but not systemd. Therefore, they suggested merely > dropping the Breaks without adding to the maintainer script. > > I am fine either way. Dropping the breaks is what makes package > installation no longer fail. > > Aurelien, are you happy with doing an upload with or without maintainer > script changes? > > Release team, can you vaguely pre-approve the attached patch with or > without maintainer script changes? Thanks Helmut for working on that. The patch looks good to me, and I would definitely prefer to include the maintainer script changes, in order to avoid bugs and mails during the lifetime of trixie. I have looked at the patch, and it's essentially the code that was there up to 2.38-13, limited to systemd restart and with #1074607 fixed, so the risks are quite low. I plan to submit an unblock pre-approval with this change with an update to the latest upstream stable branch (only small changes to the test infrastructure and sparc32). Please shout quickly if you disagree. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net
Attachment:
signature.asc
Description: PGP signature