Hi , On Fri, Nov 04, 2016 at 01:32:50AM +0200, Johannes Schauer wrote:
> Consider the following EDSP input which represents the core of the situation > we > are talking about: > > --%<-------------------------------------------------- > Request: EDSP 0.5 > Install: sbuild-build-depends-ocamlbuild-dummy:amd64 > Strict-Pinning: no > > Package: sbuild-build-depends-ocamlbuild-dummy > Architecture: amd64 > Version: 0.invalid.0 > APT-ID: 52830 > APT-Pin: 500 > Depends: ocaml-best-compilers (>= 4.03.0) > > Package: ocaml-native-compilers > Architecture: amd64 > Version: 4.03.0-5 > APT-ID: 53875 > APT-Pin: 1 > Provides: ocaml-best-compilers (= 4.03.0-5) > > Package: ocaml-native-compilers > Architecture: amd64 > Version: 4.02.3-7+b1 > APT-ID: 34663 > APT-Pin: 500 > Provides: ocaml-best-compilers > -->%-------------------------------------------------- > > With the above in /tmp/dump.edsp I get: > > $ apt-cudf -v --solver=aspcud -c "-removed,-changed,-new" /tmp/dump.edsp > Install: 34663 > Package: ocaml-native-compilers > Version: 4.02.3-7+b1 > Architecture: amd64 > > Install: 52830 > Package: sbuild-build-depends-ocamlbuild-dummy > Version: 0.invalid.0 > Architecture: amd64 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. -Ralf.
