On Tue, Dec 13, 2011 at 08:29, Guillem Jover <guil...@debian.org> wrote: > On Mon, 2011-12-12 at 18:15:12 +0100, David Kalnischkies wrote: >> 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?
Because 'apt-get remove libc6' will not remove libc6:amd64 and libc6:i386 like dpkg, but only :native - simple for the reason that it should be the reverse of 'apt-get install libc6' which installs only libc6:native, too, and not all possible architectures - as it does the same for all packages and not based on M-A state as this might change over time. The idea of not printing the architecture for M-A:foreign packages is also a dpkg-vs-apt thing as APT needs to provide the user with a way to choose which architecture should it be and if it changes the architecture it has to display this somehow and showing 'removing libc-bin; installing libc-bin' isn't exactly useful to understand what actually happens. Beside that we will have packages which are not M-A:foreign and i am not keen on telling users that they have to check which M-A state their package has before they can request and/or understand the request. That only one architecture can be installed at a given time doesn't mean the user couldn't request anything else and M-A states do not change over time. Best regards David Kalnischkies -- 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/CAAZ6_fDnkYz3Rij-FUapOvSAMyy5ZACfXC35bD1bdeS=flb...@mail.gmail.com
