On Mon, 2011-12-12 at 18:15:12 +0100, David Kalnischkies wrote: > On Mon, Dec 12, 2011 at 14:37, Raphael Hertzog <hert...@debian.org> wrote: > > On Mon, 12 Dec 2011, David Kalnischkies wrote: > > > If that's really meant, i am very worried how release upgrades should > > > work, given that squeeze tools obviously don't know about this need… > > > > This proves that we can't make dpkg fail when it gets an unqualified > > package name in input. So in the alternatives that guillem proposed > > we have to pick "pkgname = pkgname:*" so that things keep working > > during upgrade when an old APT drives a new dpkg and that some M-A > > libraries are already installed.
> So, i am able to (on native=amd64): > dpkg --unpack libc6_i386.deb # unpacking libc6:i386 > dpkg --unpack libc6_amd64.deb # unpacking libc6:i386 > dpkg --configure libc6 # configuring libc6:amd64 and libc6:i386 > dpkg --configure libc6:i386 # does this fail? If the user does this manually why would they do this last one? Or why those two instead of: dpkg --configure libc6:amd64 dpkg --configure libc6:i386 > dpkg --remove libc6 # removing libc6:i386 and libc6:amd64 > ? > Users will "love" you for this, given that it is completely inconsistent with > what front-ends will understand if the architecture is omitted… Why will the front-ends have a different understanding than dpkg then? Also consider the above scenario cannot happen from an apt session, as that requires a multiarch enabled dpkg, i386 to be added to the dpkg foreign architectures, and a multiarch enabled apt, or the latter would not be able to install both instances of libc6. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111213072932.ga29...@gaara.hadrons.org
