Bug 1388746 - Ignoring pre-existing repoclosure problem
Summary: Ignoring pre-existing repoclosure problem
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: rpmdeplint
Classification: Community
Component: cli
Version: 1.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-26 05:10 UTC by Roman Joost
Modified: 2016-10-26 05:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-26 05:49:19 UTC


Attachments (Terms of Use)

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


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