On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote: > It seems correct at first glance, but not enough to solve all the issues > mentioned. Currently existing package relationships lack information > that is necessary to do the right thing in all cases. Consider different > kinds of dependencies a package P can have on package Q:
Let me attempt to draw these. > 1) P contains code for <arch> that links with code from Q. > Q needs to work for <arch>. P (any) -> Q (any) > 2) P executes a binary provided by Q. > Any arch for Q is OK. P (any) -> Q (any) Most likely Q is M-A:foreign here. Alternatively M-A:allowed with a different dependency: P (any) -> Q:any (any) Another variation comes if P is Arch:all, but those cases work similarly to the first one. > 3) P runs a script using system interpreter X, and depends on the > interpreter environment supporting functionality provided by Q. > Q needs to work for the arch matching installed version of X. P (all) +--> X (any) `--> Q (any) The interpreter will most likely be M-A:allowed. So all P has to do here is not add ":any" to its dependencies. Then everything should work out here. X and Q would usually have singleton sets for their virtual architectures. (Only Arch:all and M-A:something packages can have non-singleton sets here.) The dependencies of P are considered satisfied only if those singleton sets are equal. > 4) P runs a script in an embedded interpreter in its <arch> code, and > depends on the interpreter environment supporting functionality > provided by Q. > Q needs to work for <arch>. Since P uses an interpreter X, it has to depend on it as well. So the resulting dependency graph should look exactly like the one above, except that P is arch:any now. > In the most common case dependencies on a package Q are either all of > type 1 or all of type 2, as long as Q only exposes one kind of > interface; in the current multiarch spec Q indicates this by > "Multi-Arch: same" for 1 and "foreign" for 2. However, dependency types > 3 and 4 require adding more information in the depending package to > allow determining what arch needs to be supported for Q. The new dependency resolution is designed to catch precisely the cases for 3 and 4 with no further annotations, because those annotations are not necessary. We just assume that a package needs all of its dependencies in the same architecture unless there are declarations that lift this requirement. Currently there are two declarations that can do this. 1. M-A:foreign tells the resolver that the rdep should not care about this particular package's architecture. 2. A package:any annotation (for M-A:allowed dependencies) says that the architecture of this particular dependency should be ignored. In the light of the above I do not quite understand what is missing to support your use cases yet (besides an implementation). Can you explain them in more detail? Examples would be helpful. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420122744.ga17...@alf.mars