On Wed, Feb 16, 2011 at 05:12:03PM +0100, Goswin von Brederlow wrote: > It actually makes less sense. > You have identified the 2 cases of arch:all apckages: > 1) truely architecture independent and satisfies dependencies for any > arch > 2) meta packages that are placeholder for an arch:any package > So why then forbid the use of the Multi-Arch field to let maintainers > choose between the 2 types? What? We didn't do that at all. This thread is about making it clear that the Multi-Arch field *can* be set on Architecture: all packages! Case 1 is Multi-Arch: foreign; case 2 is Multi-Arch: none. > The other solution is to let arch:all packages fullfill depends for any > arch but consider them as if they were arch:any when computing the > closure of dependencies. That means things the arch:all package depends > on must be the same arch as the package depending on the arch:all > package or Multi-Arch: foreign. > Dependency chains could then look like this: > foo:i386 -> bla-plugins-meta:all -> bla-plugin:i386 > foo:amd64 -> bla-plugins-meta:all -> bla-plugin:amd64 Which requires the package manager to keep track of state about *transitive* dependencies. Which is what I think we should avoid, especially for dpkg. Raphaël seems to agree with me, and has implemented my request in his branch. > "Pre-multiarch, architecture-dependent packages may depend on > Architecture: all packages and assume that the transitive dependencies > will be resolved using packages of the same architecture or other > packages that are Architecture: all." > Under multiarch the "same architecture" would mean the same architecture > as the package depending on the arch:all package. > Now you seem to say that the second chain would be illegal. Which > matches the next sentence in the specs: > "To avoid breaking this assumption, Architecture: all packages will, at > least initially, be treated as equivalent to packages of the native > architecture for all dependency resolution." > But that seems unneccessary. You only need to use the same, not the > native architecture. There is no way to know that it's the same architecture without having to fully traverse the dependency tree. That's the complexity that should be avoided in dpkg. By smashing these to :native instead of :same, we have enough information to decide *locally* whether a given package's dependencies are satisfied. Robust, efficient, and avoids getting hung up on hypothetical corner cases. -- 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