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

Aurelien Jarno <[email protected]>
Newsgroups gmane.linux.debian.apt.devel
Message-ID <aHZIPB6wcxJ6dWGQ__36894.2263348558$1752582329$gmane$org@aurel32.net>
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
[email protected]                     http://aurel32.net
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmh2SDgACgkQE4jA+Jno
M2v6bg//fbnuN70XCV87fua1JiFG8Xj81hG2bwJP4dnP7NOZgdBHFsMT6QFcyT9g
enmMpt+PhhMX/8XRnRkvS3MBZ7ALPsRJfaR0EpY2Btfc2oWuxlHrOmTpSsYilnkb
6O6JACN5m1ItINYWh7Gct6CdImf0rI6X0g0u6sDmYn5dAh6KlJq/4jtccLf03CC+
QGNS4Saz+win0VDb0DwA8w8RGcKbLbDrSkX0aPYzi9GIiSD7l2LfkZeVkjrKHD7H
cAqyU2WE6zZyT48UpRiSgLM1yObSKdiTDppZ/oarHiv2I9z5Sg16AieUOAP11Ea5
FG69G27yxBOaUVja/u4r3F495SsylSDJIOeY3YR9Q5X4HDVyfEOz432YNZaK8VHt
K6AcMnOBt+D5pnMq6S7ZpD64CSSO8U++0BT/vzmqyM+22sBohXd9o2yveew4PaPW
Bp8LLc6QXqkZ5e9ryvTJD9K83DMf3194IcVAbAxF7dea0hghFmKx95auPMo/KB2I
xbUcnuJVlDS/nsmnMA3CJtABsy+oPFmzFINClUAHu2Oef+jBmBtYWyp2iHCklUwL
38yGoeNaRTlXgOUvO09z3+N9uxmNmRVcNQBwFgC5XkWXI+9Hz2DXW3XKLcs9jEeu
4Y09CcJp6eaHycY5CdMnqH0pXVSyXsmwpXjSlgxhREjVZWuaAVM=
=xfov
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.