Zif backport repository for F15 available for testing

[Jef Spaleta]

On Tue, Sep 20, 2011 at 7:10 PM, Kevin Kofler <kevin.kofler at chello.at>wrote:

>
> (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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110922/cd446bef/attachment.html