[Git][glibc-team/glibc][sid] debian/testsuite-xfail-debian.mk: Update tests
Samuel Thibault pushed to branch sid at GNU Libc Maintainers / glibc Commits: 43d5bc4c by Samuel Thibault at 2021-07-27T02:11:53+02:00 debian/testsuite-xfail-debian.mk: Update tests - - - - - 1 changed file: - debian/testsuite-xfail-debian.mk View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/43d5bc4c0634e8a0b6461a3b9f57cedf9bb142bf -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/43d5bc4c0634e8a0b6461a3b9f57cedf9bb142bf You're receiving this email because of your account on salsa.debian.org.
Re: Preparing for glibc 2.34: library locations
* Michael Hudson-Doyle: > (but then, dpkg is not > impacted by the symbolic link issue as far as I know). > > Is this problem written up somewhere? I only subscribed to libc-alpha > a few weeks ago. I've written about it in various places. As far as I know, it's specific to how RPM performs package updates. Files removed in an update are only removed towards the end, after all work on *all* packages has been done. With the previous approach, this means that when downgrading from glibc 2.29 to glibc 2.28, during the update, there are files ld-2.28.so ld-2.29.so libc-2.28.so libc-2.29.so RPM immediately updates the dynamic linker symbolic link target from ld-2.29.so to ld-2.28.so. But if ldconfig is invoked, it will prefer libc-2.29.so over libc-2.28.so as the provider of the soname libc.so.6, and update the symbolic link and cache to point to libc-2.29.so. That is of course no good once the downgrade is finally completed and libc-2.29.so is removed. The dynamic linker and the libc.so.6 symbolic link can also become desynchronized, and then failures happen earlier during the update procedure. I believe dpkg handles file removals during upgrades/downgrades before running scripts, so it shouldn't suffer from this problem. But I believe the simplification is still worth it. Thanks, Florian
Re: Preparing for glibc 2.34: library locations
On Mon, 26 Jul 2021 at 19:16, Florian Weimer wrote: > * Michael Hudson-Doyle: > > > There is another wrinkle of course in that Debian/Ubuntu install these > > files to /lib/$multiarch/, not /lib or /lib64 as upstream expects. > > > > What I've implemented[0] for Ubuntu (only for testing so far) is to > > install libc to /lib/$multiarch/libc.so.6, the dynamic linker to > > /lib/$multiarch/$dynamic_linker_soname, and then have a symlink from > > the ABI-mandated dynamic linker path to the new path for the dynamic > > linker. This feels like a reasonable compromise between the upstream > > changes and what Debian does to me but I'm certainly interested in > > hearing other opinions (ideally before Ubuntu feature freeze :-p). > > I agree that this layout is reasonable. Thanks for thinking about it! > The target of the remaining > symbolic link is stable, so it does not matter for the issues that we > tried to address with this upstream change Right, I'm not an expert in this stuff but I tried and failed to think of ways upgrades could go wrong. > (but then, dpkg is not > impacted by the symbolic link issue as far as I know). > Is this problem written up somewhere? I only subscribed to libc-alpha a few weeks ago. > Would you please consider contributing your multiarch patches upstream? > I see no problems in principle. As above though I've only been seriously involved in glibc maintenance for maybe a month so I'm a bit lacking in context :) Cheers, mwh > Thanks. > > Florian > >
Re: Preparing for glibc 2.34: library locations
* Michael Hudson-Doyle: > There is another wrinkle of course in that Debian/Ubuntu install these > files to /lib/$multiarch/, not /lib or /lib64 as upstream expects. > > What I've implemented[0] for Ubuntu (only for testing so far) is to > install libc to /lib/$multiarch/libc.so.6, the dynamic linker to > /lib/$multiarch/$dynamic_linker_soname, and then have a symlink from > the ABI-mandated dynamic linker path to the new path for the dynamic > linker. This feels like a reasonable compromise between the upstream > changes and what Debian does to me but I'm certainly interested in > hearing other opinions (ideally before Ubuntu feature freeze :-p). I agree that this layout is reasonable. The target of the remaining symbolic link is stable, so it does not matter for the issues that we tried to address with this upstream change (but then, dpkg is not impacted by the symbolic link issue as far as I know). Would you please consider contributing your multiarch patches upstream? Thanks. Florian
