Quoting Ralf Treinen (2016-11-04 17:33:13) > thanks for having investigated that. I can imagine what happenend: The > semantics of CUDF says that a virtual package without a version > satisfies a dependency on it with *any* version constraint, that is > a virtual package without a version can be thought of as having any > possible version. > > That explains to me why the translation to CUDF is that way: it simply > mirrors the semantics of CUDF. > > Now, whether this is a bug or not is difficult to say. We don't have any > document that specifies what is supposed to happen in this situation. > I am not sure whether the current behaviour of apt should be taken as > the final word. Suppose the following situation (Architecture field omitted for brevity): Package: a Version: 1 Depends: c (>= 2) Package: b Version: 1 Provides: c Clearly, "a" is unsatisfiable (and distcheck agrees) because versioned dependencies only work on real packages or on packages providing an exact version. Now lets replace package "b" by package "d". Package: a Version: 1 Depends: c (>= 2) Package: d Version: 1 Provides: c (= 2) Clearly, "a" is satisfiable because now d provides a specific version of c. The weirdness occurs if we mix above two cases and have b and d in the universe at the same time. Package: a Version: 1 Depends: c (>= 2) Package: b Version: 1 Provides: c Package: d Version: 1 Provides: c (= 2) Suddenly, (according to distcheck) Package b is now able to satisfy the dependency of "a" even though it wasn't able to in the first situation. The only difference between the situation now and the first is, that now we have d in the mix. I do not think it makes any sense for b to only satisfy the dependency of "a" if d is part of the package universe. Instead, I think it makes sense to continue to uphold the rule: versioned dependencies can only be satisfied by real packages or by virtual packages that provide a specific version. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature