Zif backport repository for F15 available for testing

[Kevin Kofler]

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