On Thu, Dec 15, 2011 at 02:02:36AM +0100, Guillem Jover wrote: > 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.
APT can only have on native architecture during installation basically, the one defined in APT::Architecture anyway. Supporting cross-grades is not really in scope then. > > 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. So, a beginning would be to ask dpkg for the native architecture at run-time; if none is set in APT::Architecture. > > 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. That's the way Fedora did it with 32-bit/64-bit packages IIRC. Not all users are intelligent enough and will then have lots of duplicate stuff installed. We discussed command-line last year as well, see http://lists.debian.org/deity/2010/08/msg00077.html > > > 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. I don't think it was ever specified anywhere, or am I wrong? -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- 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/20111215105305.ga3...@debian.org
