Bug#1061248: glibc: DEP17: move most files but rtld to /usr
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
Reply to: