Bug 1388746

Summary: Ignoring pre-existing repoclosure problem
Product: [Community] rpmdeplint Reporter: Roman Joost <rjoost>
Component: cliAssignee: beaker-dev-list
Status: CLOSED NOTABUG QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.2CC: bmcivor, dcallagh, jorris, rjoost
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-26 05:49:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Roman Joost 2016-10-26 05:10:48 UTC
Description of problem:

Ran into another form of a pre-existing repoclosure problem.


Version-Release number of selected component (if applicable):

1.2

How reproducible:
100%


Steps to Reproduce:
1. Download these Fedora rpms: https://copr-be.cloud.fedoraproject.org/results/romanofski/gtfsschedule/fedora-24-x86_64/00469284-gtfsschedule/ from https://copr.fedorainfracloud.org/coprs/romanofski/gtfsschedule/build/469284/ (I think any Fedora package will work)
2. Run rpmdeplint against it: rpmdeplint check --repos-from-system --repo=Copr,https://copr-be.cloud.fedoraproject.org/results/romanofski/gtfsschedule/fedora-24-x86_64 /tmp/gtfsschedule-0.3.1.0-0.20161025.fc24.x86_64.rpm /tmp/ghc-gtfsschedule-0.3.1.0-0.20161025.fc24.x86_64.rpm
3. see repoclosure problems

Actual results:

Pre-existing repoclosure problems for x86_32

Expected results:

Some are genuine problems (e.g. root-io or blender(ABI)

Additional info:

Comment 1 Dan Callaghan 2016-10-26 05:28:38 UTC
Looking more closely, it seems that all these pre-existing problems are actually legit *if* you remember that rpmdeplint will only consider the latest version of a package to satisfy another package's requirements. The warning message doesn't actually make that clear (it says "nothing provides") and so I forgot about it for a minute.

The actual problem here seems to be that the x86_64 release repos contain a smattering of i686 packages (that's expected, although I forget according to which rules they are included in the release) *but* the x86_64 updates repos are missing the matching i686 packages.

So to take one of the warnings as an example:

2016-10-26 14:54:01,584 rpmdeplint WARNING Ignoring pre-existing repoclosure problem: nothing provides root-io(x86-32) = 6.06.04-1.fc24 needed by root-gui-recorder-6.06.04-1.fc24.i686

Querying against Fedora 24:

$ sudo dnf repoquery root-gui-recorder
Last metadata expiration check: 2:07:01 ago on Wed Oct 26 13:17:46 2016.
root-gui-recorder-0:6.06.04-1.fc24.i686
root-gui-recorder-0:6.06.04-1.fc24.x86_64
root-gui-recorder-0:6.06.08-2.fc24.x86_64
$ sudo dnf repoquery root-io
Last metadata expiration check: 2:07:12 ago on Wed Oct 26 13:17:46 2016.
root-io-0:6.06.04-1.fc24.i686
root-io-0:6.06.04-1.fc24.x86_64
root-io-0:6.06.08-2.fc24.i686
root-io-0:6.06.08-2.fc24.x86_64

So root-io-0:6.06.04-1.fc24.i686 does in fact provide root-io(x86-32) = 6.06.04-1.fc24 needed by root-gui-recorder-0:6.06.04-1.fc24.i686. The real problem is that root-io-0:6.06.04-1.fc24.i686 has been upgraded by root-io-0:6.06.08-2.fc24.i686. For some reason there is no 6.06.08 version of root-gui-recorder though.

Strictly speaking, yum/dnf will be able to use the older version of root-io.i686 to satisfy the dependency but it can potentially break or cause confusion if the .x86_64 package is also installed. That scenario is the cause of yum's infamous massive "multilib version problem found" error message. So that's why rpmdeplint is treating it as an unsatisfied dependency.

Comment 2 Dan Callaghan 2016-10-26 05:32:43 UTC
I didn't check all the warning reported, but a large number of them are for subpackages of that (bizarrely named) "root" package and are presumably the same problem as comment 1.

Picking some other warnings at random, they are all legitimate (mostly packages which are built against libraries which have changed soname in an update).

Comment 3 Dan Callaghan 2016-10-26 05:49:19 UTC
So I think this is NOTABUG because all the issues I have examined are legitimate.

Some package maintainers might argue that bumping soname in a stable update is okay, but it's really not, according to:

https://fedoraproject.org/wiki/Updates_Policy

"Package maintainers MUST:
    Avoid Major version updates, ABI breakage or API changes if at all possible."