Bug#1108193: apt: Ordering issue with libc6:i386 on amd64-m-a system breaks partial upgrade ("just apt and dpkg") from bookworm to trixie

On 15/07/2025 14:23, Aurelien Jarno wrote:
> 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.

Please go ahead.

Cheers,
Emilio