Bug 928117

*** 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.