On Sat, 12 Aug 2017 10:45:29 +0800, Chenxiong Qi wrote:
[root@e151b05870c7 pkgs]# dnf repoquery koji
Last metadata expiration check: 0:01:39 ago on Sat Aug 12 02:25:14 2017.
koji-0:1.10.1-13.fc25.noarch
koji-0:1.13.0-2.fc25.noarch
and koji-1.13 is listed by resolving the dependencies
[root@e151b05870c7 pkgs]# dnf repoquery --requires --resolve fedpkg
Last metadata expiration check: 0:04:56 ago on Sat Aug 12 02:25:14 2017.
bodhi-client-0:0.9.12.2-6.fc25.noarch
fedora-cert-0:0.6.0.1-1.fc25.noarch
koji-0:1.13.0-2.fc25.noarch
packagedb-cli-0:2.14.1-1.fc25.noarch
pyrpkg-0:1.46-5.fc25.noarch
python-0:2.7.13-2.fc25.i686
python-0:2.7.13-2.fc25.x86_64
python-fedora-0:0.8.0-2.fc25.noarch
python-libs-0:2.7.13-2.fc25.i686
python-libs-0:2.7.13-2.fc25.x86_64
python-pycurl-0:7.43.0-4.fc25.x86_64
python2-fedora-0:0.9.0-6.fc25.noarch
python2-pycurl-0:7.43.0-6.fc25.x86_64
python2-rpkg-0:1.49-6.fc25.noarch
redhat-rpm-config-0:45-1.fc25.noarch
The problem is, when start to install fedpkg, koji-1.10 is resolved
rather than version 1.13
[root@e151b05870c7 pkgs]# dnf install fedpkg
Last metadata expiration check: 0:10:38 ago on Sat Aug 12 02:25:14 2017.
Dependencies resolved.
============================================================================================
Package Arch Version
Repository Size
============================================================================================
Installing:
...
koji noarch 1.10.1-13.fc25
fedora 279 k
...
This problem does not affect fedpkg but also other packages, e.g.
bodhi-client and packagedb-cli, that has "Requires: koji" in SPEC
file. I created a fake package with only koji in Requires, this
problem can also be reproduced with it.
Your analysis is incomplete. It's not sufficient to claim there is an
issue. "Requires: koji" is non-versioned, so the depsolver behaviour is
implementation dependent. It may pull in _either_ build of the koji package
to satisfy the dependencies. There is no rule [yet] that would pull in the
latest EVR of a package already when installing it for the first time. Yum
hasn't done it, with its author refusing to change that behaviour, and DNF
probably mimics that behaviour. A subsequent "dnf update" may update koji
immediately. Have you tested that?
Further, it is absolutely normal that some packages exist in the repos
with multiple builds. For example, the initial release in the [fedora]
repo, an update in the [updates] repo, and for several years in the past,
older repository maintenance tools have kept multiple builds in the repos.
That could become the default again in the future.
And finally, it could be that there's a real issue that would require a
detailed look at the packages, which may cause dnf to not choose the
latest koji for the initial transaction set.