Re: multiarch and interpreters/runtimes
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
Reply to: