Re: Multiarch interfaces: print foreign arches, pkgname I/O
Hi!
On Tue, 2011-12-13 at 23:46:35 +0100, David Kalnischkies wrote:
> On Tue, Dec 13, 2011 at 08:29, Guillem Jover <guillem@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
Reply to: