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 <aurelien@aurel32.net> 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.)
Reply to: