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

Re: Multi-arch and dependencies on arch: all packages

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

> "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

Reply to: