Bug#1061248: glibc: DEP17: move most files but rtld to /usr
Hi Helmut,
I finally got time to look at your patch and do very basic testing of
it. Overall it looks good, I have a few points or questions.
On 2024-02-04 21:20, Helmut Grohne wrote:
> So here is an updated patch with a few notes:
> * This patch moves all the files including the runtime dynamic linker
> in the main multiarch library. Therefore, this patch needs to be
> synced with the corresponding base-files change to add the aliasing
> symlinks or debootstrap breaks. In other words: Don't upload this
> yet.
Ok.
> * As mentioned earlier, only the multiarch packages install the runtime
> dynamic linker via data.tar. All the multilib packages install it via
> maintainer scripts now.
> * When installing libc6-x32, /libx32 will be created because partial
> upgrades might otherwise be broken. Removing libc6-x32 will not
> remove /libx32 though. I suggest fixing this in base-files by
> installing a trigger interest in /usr/libx32 and having
> base-files.postinst create/remove /libx32 as needed. This way, we
> centralize the management of aliasing links into base-files. libx32
> only serves as an example here and it works the same way for any
> other non-essential multilib directory. Do you agree with the
> approach?
It sounds good yes. I never liked the fact the fact that the top level
symlinks like libx32 have to be handled by libc6. I explained that
clearly in #926699, and even suggested to do that in base-files, however
I didn't get the clever idea to use triggers. I got pressure from a
member of the TC to be constructive and given I didn't have a patch to
provide, I had to accept getting it managed by glibc...
> * The multilib packages install a trigger interest on the runtime
> dynamic linker such that they notice when a multiarch package deletes
> it and can then recreate it as needed. Thus the multiarch packages do
> not have to pay attention to a possibly installed multilib package
> when they are removed.
Does it means we can just remove the Replaces: in the multiarch and
multilib libc? It should not be necessary anymore, even if without file
conflicts, they should not be an issue. However not sure what could
happen during the upgrade between the old and new packages.
> * I've tried quite a few multiarch upgrades involving amd64 and i386
> using dpkg --auto-deconfigure --unpack with various packages and even
> cross grading libc6-x32 from :i386 to :amd64 during the upgrade.
> While dpkg --verify was occasionally unhappy during a partial upgrade
> (where half-unpacked packages were around), once no package was
> half-installed, dpkg --verify was also happy again in all attempts. I
> did not come up with a systematic enumeration of possible upgrade
> scenarios though.
Great.
> * The patch works will deboostrap/cdebootstrap/mmdebstrap (in
> combination with more patches including base-files, bash, dash and
> util-linux).
Ok
> * The change to install ldconfig to /usr/sbin can be uploaded right
> away. It's limited to debian/debhelper.in/libc-bin.install and
> debian/debhelper.in/libc-bin.lintian-overrides and doesn't contribute
> much diff, so doing it later is fine as well.
Ok noted. The idea was to get the 2.38 into testing, but the glibc
transition is currently blocked by the time_t transition, so the
development is currently stalled, and I am not sure when we'll do an
upload.
I also noticed that you clearly marked the code that can be removed only
after "released:forky", thanks for doing so. Do you really mean after
forky is released, so in the development cycle of forky+1? Or do you
mean for the release of forky, so in the development cycle of forky?
Cheers
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: