Bug#762073: libc6: libc6 declares 'Multi-Arch: same' but is not coinstallable on some arches
On Thu, Sep 18, 2014 at 03:31:33PM -0700, Ben Longbons wrote: > On Thu, Sep 18, 2014 at 10:18 AM, Aurelien Jarno wrote: > > On Wed, Sep 17, 2014 at 11:55:01PM -0700, Ben Longbons wrote: > > This is a known problem, but there is no way to define cross-architecture > > conflicts with the current dependencies system, and the conflicts/provides > > doesn't work either as long as we keep providing biarch or triarch > > packages. This bug is therefore not going to be fixed until a technical > > solution is found. > > Can't you just: > * split out ld.so into a separate debian package whose name depends on > the actual path That's not something possible, we don't want to break systems. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918230319.gc14...@hall.aurel32.net
Bug#762073: libc6: libc6 declares 'Multi-Arch: same' but is not coinstallable on some arches
On Thu, Sep 18, 2014 at 10:18 AM, Aurelien Jarno wrote: > On Wed, Sep 17, 2014 at 11:55:01PM -0700, Ben Longbons wrote: > This is a known problem, but there is no way to define cross-architecture > conflicts with the current dependencies system, and the conflicts/provides > doesn't work either as long as we keep providing biarch or triarch > packages. This bug is therefore not going to be fixed until a technical > solution is found. Can't you just: * split out ld.so into a separate debian package whose name depends on the actual path * mark that package Multi-Arch: none instead of Multi-Arch: same * specify appropriate depends/conflicts/replaces/whatever * Be VERY, VERY, careful that the symlink exists at all times during the upgrade, no matter what the unpacked/installed status is of libc6 and the new package? That way: * libc6:amd64 will depend on libc-ld-symlink-lib64-ld-linux-x86-64-so-2 (which must be from the same arch. i.e. amd64) * libc6:i386 will depend on libc-ld-symlink-lib-ld-linux-so-2 (which must be from the same arch, i.e. i386) * libc6:powerpc and libc6:mips will both depend on libc-ld-symlink-lib-ld-so-1 (which must be from the proper arch, and which automatically conflicts with the same package from another arch) * People with special needs for cross-building can create an empty Arch: all package and always pass --dynamic-linker= to ensure that we can run testsuites. (I already tried using dpkg-divert to move the file out of the way, but you can only do one diversion, so install at most two packages.) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+XNFZNQQi4iN-Whs8OCcjY=dd1iyfmbwdhuq6q3_obhdtc...@mail.gmail.com
Bug#762073: libc6: libc6 declares 'Multi-Arch: same' but is not coinstallable on some arches
On Wed, Sep 17, 2014 at 11:55:01PM -0700, Ben Longbons wrote: > Package: libc6 > Version: 2.19-11 > Severity: normal > > Dear Maintainer, > > While testing cross toolchains [1], dpkg bailed out when trying to > overwrite a shared file with different contents. > > Particularly, /lib/ld.so.1 is different on powerpc, mips, and mipsel. > I only checked arches listed under 'Foreign Architectures' below; > upstream has list at https://sourceware.org/glibc/wiki/ABIList > > Since ld.so is the single most important file on a system, it is hard-coded > in all existing binaries, but at least the conflict needs to be declared. This is a known problem, but there is no way to define cross-architecture conflicts with the current dependencies system, and the conflicts/provides doesn't work either as long as we keep providing biarch or triarch packages. This bug is therefore not going to be fixed until a technical solution is found. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918171848.gl...@hall.aurel32.net
Bug#762073: libc6: libc6 declares 'Multi-Arch: same' but is not coinstallable on some arches
Package: libc6 Version: 2.19-11 Severity: normal Dear Maintainer, While testing cross toolchains [1], dpkg bailed out when trying to overwrite a shared file with different contents. Particularly, /lib/ld.so.1 is different on powerpc, mips, and mipsel. I only checked arches listed under 'Foreign Architectures' below; upstream has list at https://sourceware.org/glibc/wiki/ABIList Since ld.so is the single most important file on a system, it is hard-coded in all existing binaries, but at least the conflict needs to be declared. (Theoretically, Debian doesn't officially need to support binaries that don't come from .deb packages or Debian-provided gcc, so it might be possible to remove the conflict in the long term. Practically, it would be dangerous to change it on native arches, but sufficient packaging magic can ensure that users who don't opt in never see the difference.) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armel powerpc arm64 armhf mips mipsel Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libgcc1 1:4.9.1-14 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.53 pn glibc-doc ii locales2.19-11 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918065501.12086.9558.reportbug@joyplim
