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

Bug#613584: apt-get not handling Multi-Arch: foreign, Arch: all packages correctly

On Tue, Feb 15, 2011 at 10:59:25PM +0100, David Kalnischkies wrote:
> On Tue, Feb 15, 2011 at 22:03, Steve Langasek <vorlon@debian.org> wrote:
> > This may be because the Multiarch spec was confusing on the point of Arch:
> > all packages, for which I apologize.  The spec has been updated to make it
> > clear that Multi-Arch: foreign is allowed for Arch: all packages, and an
> > explanation sent to the dpkg mailing list:

> >  http://lists.debian.org/debian-dpkg/2011/02/msg00021.html

> > Raphael has already committed the fix to the experimental multiarch branch
> > for this.  Can you please adjust the apt resolver to match?

> Urgh… I really assumed that Multi-Arch field on arch:all packages are
> illegal and that arch:all is automatic foreign as it sounds rather counter
> intuitive to have an architecture independent package which needs to
> specify explicitly that it is architecture independent and can therefore
> be used as foreign…

> The whole concept of pseudo-packages emerged from the need to make arch:all
> packages upgradeable (especially if changed from any to all and v.v. which
> still has some smaller problems, but thats a different track) and architecture
> dependent in a sense that any -> all -> any dependencies doesn't use
> different any's. The pseudo-package thing allows the resolver to think
> always in pseudo dependent packages. Pseudo packages just have an internal
> MultiArch flag indicating that they are 'all' packages and they depend on
> an architecture independent 'all' package (with no dependencies) which is
> mostly used in the ordering and download system (pseudo packages can't be
> downloaded - and configuring a pseudo package means that the 'all'
> package and therefore also all pseudo packages are configured).

> So do you have another example why this would be needed as your python
> example should be dealt with the pseudo-package concept described here?
> (Its discussed/documented in more detail in README.MultiArch)

I don't have other examples besides python off-hand.  But even if we decide
python is an exception and that the package should be fixed (how?  making it
arch: any?), a multiarch apt needs to correctly handle packages /as they
exist today/, not just packages as we think they should exist later.  If we
treat an arch: all package as satisfying dependencies on any arch, the
package manager will inevitably allow broken upgrade solutions in some cases
and possibly break the user's system entirely. :/

> If this is really changed now, I guess (I haven't touched multiarch
> internal for a while, so I am not completely sure what is needed exactly)
> I will have a lot of work for the next weeks, so let me end with my
> beginning words: Urgh

> P.S.: I haven't checked why the install itself fails. The Multi-Arch
> marker is at least completely ignored by APT for all packages.  Could you
> tell me in more detail how i need to setup my system to hit this problem?

Oh, really?  If it's ignored, I guess that's a separate bug!  Let me work on
reproducing this in a from-scratch chroot; in the meantime if you want to
play with the packages, I have a ppa of multiarchified packages here:


They're built against Ubuntu natty, but I'm just installing them against a
sid chroot at the moment for testing.

(Note: the dpkg in that ppa doesn't support actually *installing* multiarch
packages; this one is just patched for use as a build-dependency, with a
dpkg-architecture that knows about the proposed non-GNU multiarch paths.)

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: