On Mon, May 19, 2014 at 02:01:15PM +0200, Jakub Wilk wrote: > * Aurelien Jarno <aurel...@aurel32.net>, 2014-05-19, 13:28: > >>>i386 /lib/ld-linux.so.2 > >> > >>Provides: lib-ld-linux-so-2 > >>Conflicts: lib-ld-linux-so-2 > >>Replaces: lib-ld-linux-so-2 > > > >So following your way, it would be exactly the same for libc6:sparc. > > > >libc6-i386 also provides /lib/ld-linux.so.2. It should be > >co-installable with libc6:i386, but libc6:sparc should not be > >co-installable with libc6:i386 or libc6-i386. > > Oh, right. Couldn't the biarch packages die already? :)
Unfortunately, as long as we keep GCC, we will need them, even if they are a pain. > If they can't, I suppose you can implement cross-architecture > conflicts with plain conflicts against virtual packages: > > Package: libc6 > Architecture: i386 > Provides: libc6-on-i386 > Conflicts: libc6-on-sparc, ... > > Package: libc6-i386 > Architecture: amd64 > Conflicts: libc6-on-sparc, ... > > Package: libc6 > Architecture: sparc > Provides: libc6-on-sparc > Conflicts: libc6-on-i386, libc6-i386, ... Indeed we can encode the architecture in the Provides:. I guess we'll have script that... As a subsidiary question, do you know how to prevent libc6-amd64:i386 to be installed on a native amd64 system, but allow it on an i386 system, even with libc6:amd64 already installed? -- 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/20140519135614.ge5...@hall.aurel32.net
