Re: Multi-arch and dependencies on arch: all packages
Steve Langasek <vorlon@debian.org> writes:
> 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.
Yet Multi-Arch: same is forbidden in the specs. Which you would need for
a meta package that depends on a library.
>> 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.
You don't have to traverse the whole tree, only until you hit a package
that isn't arch:all. Also you can work around that by simply duplicating
the package internally with different Architecture strings as needed.
I totaly agree that this is a step up in complexity. It would be nice to
have though.
By smashing arch:all packages to :native you greatly reduce the
installability of packages. Lets take a simple game (freeciv) as example
and pretend this were a non-free package available for i386 only:
Package: freeciv-client-gtk
Architecture: i386
Depends: libatk1.0-0 (>= 1.29.3), ..., freeciv-data (>= 2.2.0), ggzcore-bin
Package: freeciv-data
Architecture: all
Version: 2.2.4-1
That means freeciv will be uninstallable on amd64 for no good reason.
Could we default arch:all leaf packages (no further Depends) to
Multi-Arch: foreign? That would cover data packages like the above
example. That should be local enough to check.
MfG
Goswin
Reply to: