(And besides, your example is about the worst you could pick, since if
somebody is skilled enough with package management to remove the PackageKit
frontend, surely he or she knows what to do if zif wants to pick the wrong
one. ;-) Real end users will ALWAYS have the PackageKit frontend installed.)
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.
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.
-jef
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
