Re: Multiarch interfaces: print foreign arches, pkgname I/O
On Sat, 2011-12-24 at 10:10:48 +0100, Raphael Hertzog wrote:
> On Sat, 24 Dec 2011, Guillem Jover wrote:
> > * Multi-arch enabled frontends should always use arch qualified names
> > as dpkg input for possibly ambiguous package names, to cleanly support
> > a distinct native architecture between dpkg and frontend, and make
> > possible cross-grading. This means that “M-A: same” need to be always
> > arch-qualified on input to dpkg. Non “M-A: same” foreign arch
> > packages do not need to be arch-qualified, as their usage on dpkg
> > is never ambiguous, there will always be only one installed, but
> > they could get arch-qualified, that should never be a problem.
>
> Yeah, there are cases where it's best to arch-qualify packages... for
> example you try to upgrade from a non "M-A: same" to a "M-A: same"
> package of another architecture.
That'd fall under the cross-grading case which I mentioned later on.
> > * During an upgrade to a multi-arch dpkg using a multi-arch enabled
> > frontend, the frontend cannot pass over arch-qualified pkgnames
> > to dpkg. It must verify if it can do so first by checking the
> > «dpkg --assert-multi-arch» exit code (as per my previous mail).
>
> I don't know how APT in squeeze behaves but the main problem pointed out
> so far is rather that it would use non-arch qualified package to refer to
> "M-A: same" packages of the native arch already installed and that dpkg
> should not blow up on this.
What I read as a problem was that apt cannot use arch-qualified
pkgnames unconditionally w/o possibly breaking the upgrade, but using
--assert-multi-arch solves that, so besides fixing apt I don't see
any other real problem here. Not arch-qualifying always “M-A: same”
packages, brings the problems I've stated on this thread.
regards,
guillem
Reply to: