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: https://launchpad.net/~vorlon/+archive/multiarch 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