Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: # dnf update colord Setting up Update Process Resolving Dependencies --> Starting dependency resolution --> Finished dependency resolution Nothing to do But: # yum update colord Loaded plugins: langpacks, presto, refresh-packagekit Resolving Dependencies --> Running transaction check ---> Package colord.x86_64 0:0.1.25-1.fc18 will be obsoleted --> Processing Dependency: libcolord.so.1()(64bit) for package: colord-0.1.31-1.fc18.x86_64 --> Processing Dependency: libcolord.so.1()(64bit) for package: gtk3-3.6.4-1.fc18.x86_64 --> Processing Dependency: libcolord.so.1()(64bit) for package: gnome-settings-daemon-3.6.4-3.fc18.x86_64 --> Processing Dependency: libcolord.so.1()(64bit) for package: 1:control-center-3.6.3-1.fc18.x86_64 --> Processing Dependency: libcolord.so.1()(64bit) for package: colord-gtk-0.1.22-3.fc18.x86_64 --> Processing Dependency: libcolord.so.1()(64bit) for package: gnome-color-manager-3.6.1-1.fc18.x86_64 --> Processing Dependency: libcolord.so.1()(64bit) for package: simple-scan-3.6.0-1.fc18.x86_64 ---> Package colord.x86_64 0:0.1.25-1.fc18 will be updated ---> Package colord.x86_64 0:0.1.31-1.fc18 will be obsoleting ---> Package shared-color-profiles.noarch 0:0.1.6-1.fc18 will be obsoleted --> Running transaction check ---> Package colord-gtk.x86_64 0:0.1.22-3.fc18 will be updated ---> Package colord-gtk.x86_64 0:0.1.24-1.fc18 will be an update ---> Package colord-libs.x86_64 0:0.1.31-1.fc18 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: colord x86_64 0.1.31-1.fc18 updates 317 k replacing colord.x86_64 0.1.25-1.fc18 replacing shared-color-profiles.noarch 0.1.6-1.fc18 Installing for dependencies: colord-libs x86_64 0.1.31-1.fc18 updates 112 k Updating for dependencies: colord-gtk x86_64 0.1.24-1.fc18 updates 19 k Transaction Summary ================================================================================ Install 1 Package (+1 Dependent package) Upgrade ( 1 Dependent package) Version-Release number of selected component (if applicable): dnf-0.2.21-1.git050524e.fc18.noarch
*** Bug 928118 has been marked as a duplicate of this bug. ***
*** Bug 928119 has been marked as a duplicate of this bug. ***
I can reproduce this, colord-0.1.25 can not be updated by DNF for some reason: [root@localhost ~]# dnf list available colord Available Packages colord.i686 0.1.25-1.fc18 fedora colord.x86_64 0.1.31-1.fc18 updates [root@localhost ~]# dnf --version 0.2.21 Installed: dnf-0:0.2.21-1.git050524e.fc18.noarch at 2013-03-01 10:06 Built : Fedora Project at 2013-02-11 12:00 Installed: rpm-0:4.10.3.1-1.fc18.x86_64 at 2013-03-01 09:59 Built : Fedora Project at 2013-02-06 09:54 [root@localhost ~]# dnf list available colord Available Packages colord.i686 0.1.25-1.fc18 fedora colord.x86_64 0.1.31-1.fc18 updates [root@localhost ~]# dnf update colord Setting up Update Process Resolving Dependencies --> Starting dependency resolution --> Finished dependency resolution Nothing to do
First I thought this has something to do with obsoleting of shared-color-profiles but it doesn't. It has more to do with the new colord no longer providing libcolord, this provide was moved to a new package, colord-lib. And for some reason, without forcing with --best or similar, DNF's depsolver won't go for this update path. Which is a brainer to me. Some experimenting helped boiling this down to a failing libsolv testcase: --- repo system 0 testtags <inline> #>=Ver: 2.0 #>=Pkg: c 25 1 x86_64 #>=Prv: z #>=Pkg: x 1 1 x86_64 #>=Req: z repo available 0 testtags <inline> #>=Ver: 2.0 #>=Pkg: c 25 1 x86_64 #>=Prv: z #>=Pkg: c 31 1 x86_64 #>=Req: c-libs #>=Pkg: c-libs 31 1 x86_64 #>=Prv: z system x86_64 rpm system job update name c [forcebest] result transaction,problems <inline> #>install c-libs-31-1.x86_64@available #>upgrade c-25-1.x86_64@system c-31-1.x86_64@available nextjob # shouldn't we see the same result without [forcebest]? job update name c result transaction,problems <inline> #>install c-libs-31-1.x86_64@available #>upgrade c-25-1.x86_64@system c-31-1.x86_64@available --- Michael, may I ask you for some insight here? Is everything fine or should the second job pass as well? And, what is a bit weird, it actually passes if I remove c-25 from the available repo.
It's an unintended and unwanted side effect of the "choice rules" generator. What happens is that a choice rule is added to limit the choice for the "z" capability: OLD Rule #5: !x-1-1.x86_64 [3]I (w1) c-25-1.x86_64 [2]I (w2) c-25-1.x86_64 [4] c-libs-31-1.x86_64 [6] next rules: 0 0 WEAK CHOICE Rule #10: !x-1-1.x86_64 [3]I (w1) c-25-1.x86_64 [2]I (w2) c-25-1.x86_64 [4] next rules: 0 0 I.e. it adds it because it doesn't like that "x" gets provided by some other package. The choice rule is weak, so it can easily broken by a hard rule like the ones added with forcebest, but it still kills the normal update case. As it happens quite often that sub-package get split off other packages the current behavior can be considered a bug and needs fixing. (As a side note: Ales, you really should add a --testcase option to dnf which calls testcase_write() to create a solver testcase.)
(In reply to comment #5) > As it happens quite often that sub-package get split off other packages the > current behavior can be considered a bug and needs fixing. Thanks, I'm filing this as a libsolv bug and will rebase once a libsolv fix becomes available (I became the sole libsolv maintainer recently BTW;)) > > (As a side note: Ales, you really should add a --testcase option to dnf > which calls testcase_write() to create a solver testcase.) Sure I can add that. Just to update you how I arrived at the testcase above: I started using the new '--debugrepodata' switch in DNF: https://github.com/akozumpl/dnf/commit/686bd51c082f9040067dba28d3cfd04429ff76c5 This doesn't create the complete test case for libsolv but it creates susetags repositories that I can play with first and then let them "crystallize down" by removing most packages. It helps me determine this is not a bug in DNF or hawkey.
> becomes available (I became the sole libsolv maintainer recently BTW;)) that is, sole *fedora* maintainer...
(In reply to comment #6) > This doesn't create the complete test case for libsolv but it creates > susetags repositories that I can play with first and then let them > "crystallize down" by removing most packages. It helps me determine this is > not a bug in DNF or hawkey. OK, I see now that that is a part of what testcase_write() already does. I'll switch the implementation for it.
added support for testcase_write() to DNF, commit 886c72b.
Ales, does commit 0203da27 help with the colord update?
Yes, thanks! Matthew, this will be fixed with the next libsolv rebase in F19 and rawhide. If you want to update colord using DNF in F18 you can use '--best' command line switch to force the latest version even without this fix.
libsolv-0.3.0-1.gite372b78.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libsolv-0.3.0-1.gite372b78.fc19
*** Bug 953179 has been marked as a duplicate of this bug. ***
libsolv-0.3.0-1.gite372b78.fc19, hawkey-0.3.10-1.git1d51b83.fc19, dnf-0.3.2-1.gitf3818b4.fc19, librepo-0.0.2-3.20130408git720d68d.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.