Re: Zif backport repository for F15 available for testing
Kevin Kofler wrote:
I have put up a repository with an updated zif snapshot for Fedora 15 at:
http://repos.fedorapeople.org/repos/kkofler/zif-backport/fedora-zif-
backport.repo
There's once again a new snapshot today. (I haven't announced every new
snapshot in the repository and will NOT announce them every time, just check
for updates regularly. :-) )
The repository also includes a rebuild of PackageKit to deal with the
bumped zif soname. This should only affect PackageKit-zif, but all
subpackages including the main package are rebuilt, and provided because
of the strict %{version}-%{release} dependencies.
Since there have been several bug fixes and improvements to PackageKit-zif
as well, as of NOW, the PackageKit that is provided is no longer a straight
rebuild, but has pk-backend-zif.c backported from git master (currently
20110926, but there too, I will NOT make an announcement each time I update
it). All the other PackageKit files are the same as in the Fedora 15
package, only the zif backend is backported from master. (I will only
backport other changes from master if they're needed to build the current
zif backend. Currently, no such changes are needed.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
On Tue, Sep 20, 2011 at 7:10 PM, Kevin Kofler kevin.kof...@chello.atwrote: (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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
- Original Message - 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. There's probably a pretty strong argument to be made that if package A requires foo, and packages B, C, and D all provide foo, that the proper answer (whether using zif or yum) would be to ask the user which they would prefer. Any automated system is going to be prone to being tricked one way or another. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
On Thu, Sep 22, 2011 at 10:51 AM, Doug Ledford dledf...@redhat.com wrote: - Original Message - 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. There's probably a pretty strong argument to be made that if package A requires foo, and packages B, C, and D all provide foo, that the proper answer (whether using zif or yum) would be to ask the user which they would prefer. Any automated system is going to be prone to being tricked one way or another. Wow... just wow. -jefplease hold while koji asks you a series of questions concerning multiple provider cascades to pre-populate the build environment for your rawhide scratch build that you have just requestedspaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
- Original Message - Wow... just wow. -jefplease hold while koji asks you a series of questions concerning multiple provider cascades to pre-populate the build environment for your rawhide scratch build that you have just requestedspaleta You can always have a switch to provide the old heuristic if you want. And that switch can default to on for automated environments like koji. But since you are asking questions about whether or not zif picks the right package to satisfy a dependency by default, it's fair to ask the question whether or not there *is* a right automatic dependency. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
On Thu, Sep 22, 2011 at 13:43, Doug Ledford dledf...@redhat.com wrote: - Original Message - Wow... just wow. -jefplease hold while koji asks you a series of questions concerning multiple provider cascades to pre-populate the build environment for your rawhide scratch build that you have just requestedspaleta You can always have a switch to provide the old heuristic if you want. And that switch can default to on for automated environments like koji. But since you are asking questions about whether or not zif picks the right package to satisfy a dependency by default, it's fair to ask the question whether or not there *is* a right automatic dependency. I can understand in the case where you have some knowledge of what the various package chains do. But for a lot of packages I have no clue and could care less (until I do and then I will be as cranky and unreasonable as if I had been asked a ton of questions). So in either way I would say that the package solver is in a un-winnable situation. They just need to choose one they can live/die with. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
- Original Message - I can understand in the case where you have some knowledge of what the various package chains do. Such cases do exist. The libibverbs package requires a libibverbs-driver in order to run. Which driver you want depends on hardware, and we don't normally install all of them. A user who bought the hardware in question could probably suss out which package they need to satisfy the dependency if they were asked. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
On 09/23/2011 01:39 AM, Doug Ledford wrote: - Original Message - I can understand in the case where you have some knowledge of what the various package chains do. Such cases do exist. The libibverbs package requires a libibverbs-driver in order to run. Which driver you want depends on hardware, and we don't normally install all of them. A user who bought the hardware in question could probably suss out which package they need to satisfy the dependency if they were asked. You just made the case for debconf Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
Kevin Kofler wrote: I have put up a repository with an updated zif snapshot for Fedora 15 at: http://repos.fedorapeople.org/repos/kkofler/zif-backport/fedora-zif-backport.repo So, I found several issues, mostly in zif or PackageKit-zif, but also one in KPackageKit/Apper: https://bugzilla.redhat.com/show_bug.cgi?id=739969 https://bugzilla.redhat.com/show_bug.cgi?id=739980 https://bugzilla.redhat.com/show_bug.cgi?id=739983 https://bugzilla.redhat.com/show_bug.cgi?id=739985 https://bugs.kde.org/show_bug.cgi?id=282418 I'm building a new snapshot of zif, which should fix #739980 (but I have to test that), and will be pushing it to the repository (no matter whether it actually fixes #739980 or not). I hope we can get all the annoyances in zif sorted out soon. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
On Tue, Sep 20, 2011 at 8:48 AM, Kevin Kofler kevin.kof...@chello.atwrote: I hope we can get all the annoyances in zif sorted out soon. Kevin, were you able to reproduce my problem with the official adobe repository? I'm still not sure if my multiple issues with zif depsolving are a problem with my system specifically or with zif. I'd appreciate if you could try to reproduce what I was seeing on bug 739701https://bugzilla.redhat.com/show_bug.cgi?id=739701. I'll update to your backport repo and reconfirm. Sadly... my C foo isn't as good as my python foo, so I'm not going to be much help tracking down what is going wrong in zif's parsing of the valid provide information in the repodata to result in bogus provides getting mixed into its depsolving. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
Kevin Kofler wrote: I'm building a new snapshot of zif, which should fix #739980 (but I have to test that), and will be pushing it to the repository (no matter whether it actually fixes #739980 or not). There's now zif-0.2.4-0.93.20110920git.fc15 in the repository, but you'll probably have to update to it using yum, not zif: https://bugzilla.redhat.com/show_bug.cgi?id=740068 Sorry for that, I hope that bug will get fixed soon. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
Jef Spaleta wrote: Kevin, were you able to reproduce my problem with the official adobe repository? To be honest, I haven't tried it, I've been busy enough filing the bugs for the issues I found myself and retesting them with today's snapshot. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
On Tue, Sep 20, 2011 at 1:17 PM, Kevin Kofler kevin.kof...@chello.atwrote: Jef Spaleta wrote: Kevin, were you able to reproduce my problem with the official adobe repository? To be honest, I haven't tried it, I've been busy enough filing the bugs for the issues I found myself and retesting them with today's snapshot. Fair enough, avalanche of unexpected bugs aside you have systems with just KDE and no GNOME installed yes? zif install paprefs with kpackagekit not installed does zif do the more optimal thing and pull kpackagekit in as a dep to fill PackageKit-session-service requirement? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
On Tue, Sep 20, 2011 at 16:06, Jef Spaleta jspal...@gmail.com wrote: On Tue, Sep 20, 2011 at 1:17 PM, Kevin Kofler kevin.kof...@chello.at wrote: Jef Spaleta wrote: Kevin, were you able to reproduce my problem with the official adobe repository? To be honest, I haven't tried it, I've been busy enough filing the bugs for the issues I found myself and retesting them with today's snapshot. Fair enough, avalanche of unexpected bugs aside you have systems with just KDE and no GNOME installed yes? zif install paprefs with kpackagekit not installed does zif do the more optimal thing and pull kpackagekit in as a dep to fill PackageKit-session-service requirement? On a F16 beta-ish box.. I get the following with default install: Installing: 1.paprefs-0.9.9-8.fc15.i686 (fedora) Installing for dependencies: 1.gconfmm26-2.28.2-2.fc15.i686 (fedora) 2.libglademm24-2.6.7-4.fc15.i686 (fedora) What do you want me to do to try and test it more? Install some KDE items? -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Zif backport repository for F15 available for testing
Jef Spaleta wrote: you have systems with just KDE and no GNOME installed yes? zif install paprefs with kpackagekit not installed does zif do the more optimal thing and pull kpackagekit in as a dep to fill PackageKit-session-service requirement? I'm not sure why you're asking that. It was already pointed out on more than one occasion that zif does NOT decide which provider to pick based on other installed packages, by design. But I did the test anyway: On my notebook, after removing kpackagekit, I get: Transaction summary: Installing: 1.paprefs-0.9.9-8.fc15.x86_64 (fedora) Installing for dependencies: 1.PackageKit-device-rebind-0.6.17-1.fc15.libzif.so.3.x86_64 (fedora- zif-backport) 2.gconfmm26-2.28.2-2.fc15.x86_64 (fedora) 3.gnome-packagekit-3.0.0-5.fc15.x86_64 (updates) 4.pulseaudio-module-gconf-0.9.22-5.fc15.x86_64 (fedora) Run transaction? [y/N] n User declined action After reinstalling KPackageKit, I get: Transaction summary: Installing: 1.paprefs-0.9.9-8.fc15.x86_64 (fedora) Installing for dependencies: 1.gconfmm26-2.28.2-2.fc15.x86_64 (fedora) 2.pulseaudio-module-gconf-0.9.22-5.fc15.x86_64 (fedora) Run transaction? [y/N] n User declined action FWIW, I have tons of GNOME stuff installed already (even gnome-shell), so gnome-packagekit doesn't drag in all that much extra GNOME stuff, and paprefs drags in GNOME stuff by itself, too. (In fact, the kpackagekit package would have happened to require one less dependency, but it isn't even a GNOME dependency, but a PackageKit one.) But in reality, the dependencies are not the real issue at all, the thing is that gnome- packagekit is useless in KDE unless you go and manually enable it. (Or at least it won't be fully functional, because it won't be started up automatically, e.g. to check for updates. It might get D-Bus-activated when paprefs needs it. But there are cases such as the PolicyKit 1 authentication agent where D-Bus activation is not used at all, exactly to ensure the correct agent for the running desktop environment gets used, not a random one.) What is actually needed to satisfy paprefs' dependency is: = begin pseudocode = if (GNOME installed || Xfce installed || LXDE installed) install gnome-packagekit; if (KDE installed) install kpackagekit; (In particular, if both are installed, install both, they're both needed because they'll only start in the respective desktop environment!) if (none of GNOME, KDE, Xfce, LXDE installed) install a desktop environment first, or just error; = end pseudocode = But such complex dependencies cannot be expressed in RPM. The virtual dependency is only an approximation, the general assumption being that either gnome-packagekit or kpackagekit is already installed as part of the desktop in most cases anyway. So deciding based on the dependencies as yum does is only a heuristic, which can only be an approximation to what is truly needed (see the above pseudocode). (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.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
