[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multiarch interfaces: print foreign arches, pkgname I/O

On Mon, 2011-12-12 at 14:37:36 +0100, Raphael Hertzog wrote:
> On Mon, 12 Dec 2011, David Kalnischkies wrote:
> > You talk only about output, but the title is "I/O" and i think it's unlikely
> > that dpkg has a different understanding of pkgname in output vs input,
> > so, you want to tell us that from now on we need to say (native=amd64):
> > dpkg --configure libc6:amd64 instead of
> > dpkg --configure libc6 , right?
> > 
> > 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.

Yes, and this should not be a problem as there should (normally) only
be one instance installed at that time, or apt would not be able to
handle it anyway.

> > > One option though if we'd want to preserve output compatibility could be
> > > to only allow co-installability and as such the need to disambiguate
> > > “M-A: same” instances only when a foreign architecture has been configured.
> > 
> > Not allowing foreign architectures before they are configured would be
> > preferable, given that front-ends will have a hard time to know which
> > architectures they can expect -- beside that i wouldn't understand the
> > difference between:
> > a) foreign architecture configured and
> > b) foreign architecture not-configured
> > given that dpkg would seem to accept a) and b) then without a visible
> > difference, so why configuring at all…
> Foreign architectures packages are already forbidden by default (unless
> --force-architecture is in use). I don't know what Guillem was thinking
> about, maybe dropping the possibility to override the error.

Exactly. As long as it's possible to install more than one instance
then there's the need to distinguish them, if besides the configured
foreign architectures other instances can be installed by way of
--force-architecture then just counting the number of configured
foreign architectures would not be enough to know if we need to
reliably distinguish them or not.


Reply to: