Hi all,
We currently have a problem with the libc{0.1,0.3,6,6.1} packages, which
are marked as Multiarch:same, but are in practice not co-installable due
to the ELF interpreter path being the same on various architectures. For
example libc6:i386 and libc6:sparc are not co-installable, causing dpkg
to exit complaining onifile overwrite.
Here is the list of the different ELF interpreters for the various
architectures we have in Debian or floating around:
alpha /lib/ld-linux-aarch64.so.1
amd64 /lib64/ld-linux-x86-64.so.2
arm64 /lib/ld-linux.so.2
armel /lib/ld-linux.so.3
armhf /lib/ld-linux-armhf.so.3
hurd-i386 /lib/ld.so
i386 /lib/ld-linux.so.2
hppa /lib/ld.so.1
ia64 /lib/ld-linux-ia64.so.2
kfreebsd-amd64 /lib/ld-kfreebsd-x86-64.so.1
kfreebsd-i386 /lib/ld.so.1
m68k /lib/ld.so.1
mips /lib/ld.so.1
mipsn32 /lib32/ld.so.1
mips64 /lib64/ld.so.1
mipsel /lib/ld.so.1
mipsn32el /lib32/ld.so.1
mips64el /lib64/ld.so.1
powerpc /lib/ld.so.1
powerpcspe /lib/ld.so.1
ppc64 /lib64/ld64.so.1
ppc64el /lib64/ld64.so.2
s390 /lib/ld.so.1
s390x /lib/ld64.so.1
sh4 /lib/ld-linux.so.2
sparc /lib/ld-linux.so.2
sparc64 /lib64/ld-linux.so.2
x32 /libx32/ld-linux-x32.so.2
As you can see even if there is some diversity, we also have a lot
of cases where the ELF interpreter is the same. We therefore have to
find a way to avoid such packages to get installed at the same time on
the systems. We first tried with a list of cross-architecture Conflicts,
but at the end, it is not fully supported by apt and breaks wanna-build
through dose3. Last but not least a package is allowed to Conflicts with
itself, so changing that would probably breaks plenty of things.
In addition to that we have to support multilib packages (also called
bi/triarch) and allow for example libc6:i386 to be coinstallable with
libc6-i386:amd64 even if they both provide the same symlink to the ELF
interpreter (but pointing to a different location). This is necessary
for example to be able to install gcc-multilib:amd64 and a few :i386
libraries on an amd64 systems to build i386 libraries. This is currently
done by a Replaces: and by recreating the symlink in the postrm when the
package is removed. This is already quite fragile, and in addition
ldconfig also play a role there by recreating some symlinks pointing to
the wrong version. It is actually possible to break a wheezy system with
just two apt-get commands. This is fixed in jessie/sid except for a few
corner cases and we have to backports the changes to wheezy, but it shows
how dealing with the ELF interpreter symlinks can easily break things.
We also would like to disallow the possibility to install
libc6-amd64:i386 on an amd64 system (this happens for example if you
just run apt-get install gdb64 on an amd64 system with a foreign i386
architecture). This currently works again in sid, but it is quite
fragile, though from the number of bug reports we got, it seems to not
be a that uncommon situation among users.
We are therefore asking for ideas how to prevent packages which
conflicts to be installed at the same time on a system, without using
cross-architecture Conflicts and without moving the ELF interpreter to
additional packages. Help is really welcomed there, as it is currently
a whole mess breaking systems.
Thanks,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140519102507.ga25...@hall.aurel32.net
