Bug 1530081 - repoclosure --best broken on multilib arches
Summary: repoclosure --best broken on multilib arches
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf-plugins-core
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Blaha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-01 19:42 UTC by Paul Howarth
Modified: 2018-06-28 08:33 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-28 08:33:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Paul Howarth 2018-01-01 19:42:57 UTC
Description of problem:
Since upgrading from Fedora 25 to Fedora 27 I have an issue running repoquery against multilib x86_64 repository sets with --best. The set of packages checked against now only includes one of the multilib arches instead of both.

Version-Release number of selected component (if applicable):
dnf-plugins-core-2.1.5-1.fc27.noarch

How reproducible:
Pretty easy.

Steps to Reproduce:
1. Use a Fedora 27 x86_64 system
2. Run "dnf repoclosure --check=updates --best"

Actual results:
Lots of errors about missing libraries, among other things, because only one of glibc.x86_64 and glibc.i686 will be checked against.
e.g.:
package: 389-ds-base-1.3.7.8-1.fc27.x86_64 from updates
  unresolved deps:
    libdb-5.3.so()(64bit)
    libdl.so.2(GLIBC_2.2.5)(64bit)
    libpthread.so.0(GLIBC_2.2.5)(64bit)
    libc.so.6(GLIBC_2.17)(64bit)
    libnspr4.so()(64bit)
    libnss3.so()(64bit)
    libnss3.so(NSS_3.9.2)(64bit)
    libns-dshttpd-1.3.7.8.so()(64bit)
    libssl3.so(NSS_3.14)(64bit)
    libssl3.so(NSS_3.2)(64bit)
    libssl3.so(NSS_3.7.4)(64bit)
    libcrypt.so.1()(64bit)
    libcrypt.so.1(GLIBC_2.2.5)(64bit)
    libdl.so.2()(64bit)
    libcom_err.so.2()(64bit)
    libldap_r-2.4.so.2()(64bit)
    libnss3.so(NSS_3.3)(64bit)
    libnss3.so(NSS_3.2)(64bit)
    liblber-2.4.so.2()(64bit)
    libldap-2.4.so.2()(64bit)
    libk5crypto.so.3()(64bit)
    libplc4.so()(64bit)
    libplds4.so()(64bit)
    libkrb5.so.3()(64bit)
    libssl3.so()(64bit)
    libpthread.so.0()(64bit)
    libnss3.so(NSS_3.12)(64bit)
    libnss3.so(NSS_3.4)(64bit)
    libsasl2.so.3()(64bit)

Expected results:
A much smaller list, consisting only of actual broken dependencies.

Additional info:
I believe this is due to an underlying change in the dnf query filter API, in which query.filter(latest=True) now only picks the one latest version of a package across all repos and arches (arbitrarily picking one arch when there are multiple with the same NEVR). The previous behavior can be obtained by using query.filter(latest_per_arch=True), which fixes this problem.

Whilst debugging this issue I also came across another change. It appears that query.latest() now behaves the same as query.filter(latest_per_arch=True), which finds the latest package per arch across all repos, whereas it used to find the latest package per arch in each repo. The result of this is that repoclosure --newest and repoclosure --best now do the same thing.

Comment 1 Jaroslav Mracek 2018-06-28 08:33:26 UTC
The issue is solved by dnf-plugins-core-3.0.1-1 that was released into rawhide.


Note You need to log in before you can comment on or make changes to this bug.