<br><br><div class="gmail_quote">On Tue, Sep 20, 2011 at 2:25 PM, Stephen John Smoogen <span dir="ltr"><<a href="mailto:smooge@gmail.com">smooge@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div>What do you want me to do to try and test it more? Install some KDE items?<br></div>
<br></blockquote><div><br>Remove the gnome DE stack entirely install the KDE stack, make sure kpackagekit is not installed and run it again. kpackagekit is probably going to be installed by default if you use yum groupinstall method as comps tags it as a default package.<br>
But you should be able to uninstall kpackagekit as nothing actually depends on it except potentially paprefs.<br><br>Does zif prefer to pull in the full gnome stack to get gnome-packagekit or does it install kpackagekit?<br>
<br>Easier to do if you start from a KDE only install target I guess. I'm just trying to test how well zif handles the multple provider case and understand how it makes the judgment on what is installed. The most likely end user cases I can think of are KDE/GNOME provider duality when there is a system that has one of the desktops installed by default but not the other. This is just the first one I attempted and hit an unrelated bug with repodata parsing. Since I'm having other problems with zif depresolution I'm wary to trust my systems until that is cleared up. And no this might not be the best real world example that people may hit due to kpackagekit being in the default comps group for KDE, its just the first one I reached for as a test.<br>
I'm sure other similar examples of the multiple provider situation exists.<br><br>-jef<br></div></div>