Hi! On Tue, 2011-12-13 at 23:46:35 +0100, David Kalnischkies wrote: > 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.
Well, if dpkg and the front-ends or even each distinct front-end has a different interface regarding this, then we have a problem. Users will certainly be way more confused this way for sure. Not getting the cross-grade case right interface-wise might imply that it becomes extremely difficult or outright impossible to implement it later on. Even then, as I stated on my initial mail, if we ignore the cross-grade case, let's consider the situation of a system with just a i386 essential package set, where an amd64 apt (and needed dependencies) have just been installed. The notion of native arch is going to be different for both dpkg and apt which depending on the interface might produce interesting results to say the least. In addition all this is for M-A: same packages, which should in most (if not all?) cases be just dependency packages, not something the user might need to request by hand, and as such if they'd need to, they can use the proper syntax. Regarding your 'apt-get install libc6', I don't see why it could not be made to install libc6 for all configured foreign architectures, which would match nicely the remove case, and would be pretty consistent. The user would see the proposed list of packages and could opt-out in case that was not wanted. > 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. Well, I'd argue that's a flaw in the current implementation then, the need for removal and reinstallation is arbitrary and not something that should be really required, dpkg has supported until now cross-grading a package to a different architecture even if it stopped doing so in some cases now on the multiarch branch, and as you pointed out already something that will definitely cause problems with essential or pseudo-essential packages. So it's something that should either be not supported at all, or supported fully, I don't think removal and install is an acceptable behaviour. 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/20111215010236.ga19...@gaara.hadrons.org
