On Thu, Sep 18, 2014 at 10:18 AM, Aurelien Jarno <[email protected]> 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=<multiarch path to the 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/CA+XNFZNQQi4iN-Whs8OCcjY=dd1iyfmbwdhuq6q3_obhdtc...@mail.gmail.com
