Re: Multiarch interfaces: print foreign arches, pkgname I/O
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 <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.
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/.
Reply to: