Re: Multiarch interfaces: print foreign arches, pkgname I/O
On Tue, Dec 13, 2011 at 08:29, Guillem Jover <firstname.lastname@example.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