Re: Multiarch interfaces: print foreign arches, pkgname I/O
On Mon, 2011-12-12 at 18:15:12 +0100, David Kalnischkies wrote:
> On Mon, Dec 12, 2011 at 14:37, Raphael Hertzog <hertzog@debian.org> wrote:
> > On Mon, 12 Dec 2011, David Kalnischkies wrote:
> > > If that's really meant, i am very worried how release upgrades should
> > > work, given that squeeze tools obviously don't know about this need…
> >
> > This proves that we can't make dpkg fail when it gets an unqualified
> > package name in input. So in the alternatives that guillem proposed
> > we have to pick "pkgname = pkgname:*" so that things keep working
> > during upgrade when an old APT drives a new dpkg and that some M-A
> > libraries are already installed.
> So, i am able to (on native=amd64):
> dpkg --unpack libc6_i386.deb # unpacking libc6:i386
> dpkg --unpack libc6_amd64.deb # unpacking libc6:i386
> dpkg --configure libc6 # configuring libc6:amd64 and libc6:i386
> dpkg --configure libc6:i386 # does this fail?
If the user does this manually why would they do this last one? Or why
those two instead of:
dpkg --configure libc6:amd64
dpkg --configure libc6:i386
> 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?
Also consider the above scenario cannot happen from an apt session, as
that requires a multiarch enabled dpkg, i386 to be added to the dpkg
foreign architectures, and a multiarch enabled apt, or the latter would
not be able to install both instances of libc6.
regards,
guillem
Reply to: