On Sun, Feb 04, 2024 at 09:20:09PM +0100, Helmut Grohne wrote: > Hi Aurelien and Sven, > > On Wed, Jan 24, 2024 at 09:19:12PM +0100, Aurelien Jarno wrote: > > On 2024-01-23 17:40, Helmut Grohne wrote: > > > Conflicting runtime dynamic linkers between multiarch packages > > > ============================================================== > > > > > > Some architecture combinations such as s390, powerpc, hppa, m68k, > > > mipsn32, and hurd-i386 or alpha, i386, sh4, and sparc have conflicting > > > runtime dynamic loaders. In theory this violates Multi-Arch: same, but > > > there is basically nothing we can do about this and dropping Multi-Arch: > > > same from the packages would completely break any kind of multiarch > > > setup. There is little we can do here and this is also unrelated to > > > DEP17. > > > > We tried to add conflicts for those, like it's done for the multilib > > packages, but at the time the infrastructure exploded (see #745552). I > > don't remember the details, but I guess it was either dak or > > dose-builddebcheck. > > Yeah, I also remember something like that. It's not the first time I > trip into this. "There is little we can do here" still counts. > > > I guess the symlink in the maintainer script could indeed work. I am not > > sure why it has been done like that, it was part of the multiarch > > patchset from Steve Langasek more than 10 years ago. > > Practically speaking, it appears to work rather well. On the flip side, > I also thought that way of my first patch. ;) > > > Note however that the those packages are used by cross-toolchain-base > > (which builds them from glibc-source) and mangled to install them in the > > cross path. See for instance libc6-amd64-x32-cross. For such cases, we > > probably do want to keep the dynamic linker symlink, as those packages > > do not have maintainer scripts. > > I don't think those -$arch-cross packages need the runtime dynamic > linker at all. Unlike the libc6-$multilib packages, we don't use > -$arch-cross packages to actaully run any binary. Simply not installing > it might just work in practice. > > 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. > * 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? > * 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. > * 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. > * The patch works will deboostrap/cdebootstrap/mmdebstrap (in > combination with more patches including base-files, bash, dash and > util-linux). > * 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. > > I hope you don't manage to punch holes into my theory this time around.
Ubuntu testing revealed that due to /lib64 going away in the package we also are going to need Depends or PreDepends on base-files, such that base-files trigger can then create the symlink. Or we temporarily handle the trigger ourselves or so. I am not sure if Depends are enough, I guess if you do a release upgrade we could end up with unpack base-files unpack libc6 preinst for something we want to unpack -> poof, no /lib64 here, can't find linker. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
