Jef Spaleta wrote:
I fully admit that this case is meant to be indicative of a class of
transactions and not a smoking gun. I was reaching for a simple to
understand virtual provides scenario, in the same vein as the test cases
that zif's compile time make check does already. I believe it is useful
example for exploring the differences in scoring and the consequences
thereof. And considering that Richard has previously stated that he feels
that yum unnecessarily installs hundreds of packages to fill a dep in some
cases, I would think he would be interested in making sure zif doesn't end
up selecting a valid solution that similarly provides an unoptimal outcome
with regard to downloaded content.
The thing is, doing the right thing there is only possible if you make the
preferred provider depend on what other packages (which don't provide the
virtual dependency) the user already has installed, and there's a case for
NOT doing that: it makes it near impossible for the packager to control what
should be the default. There are cases like your example where there
shouldn't be a default, but there are cases where there should, see e.g. my
Phonon example:
http://lists.fedoraproject.org/pipermail/devel/2011-September/157134.html
Plus, the number of direct dependencies, which yum uses, is not necessarily
meaningful. Not only doesn't it consider indirect dependencies, but it is
flawed even for direct ones, e.g. if provider A Requires: huge-monolith (or
if provider A IS the huge monolith and has no dependencies at all) and
provider B requires 2 small libraries instead, you might not want the huge
monolith.
Though to be honest, i'm much more concerned about what I'm
seeing with
regard to zif behavior on my systems with the adobe or openshift repo
enabled. I've looked through the repodata for those repositories and I
just don't see how zif is coming up with the errors it is concerning the
unsolvable transactions. Correctly handling existing 3rd party repos is
sort of important. A lot of end users use that adobe plugin repo and if
enabling it breaks zif in such a way that all transactions fail..thats a
huge problem. I could really use some confirmation from someone else to
make sure what I'm seeing isn't something confined to the particularities
of my 3 F15 systems I have here.
What you're seeing there is a bug, it's still open, I'm sure it will be
fixed.
Kevin Kofler