Bug 1199381

Summary: Don't pull in obsoleted dependencies from another package
Product: [Fedora] Fedora Reporter: Jose A. Rivera <jrivera>
Component: pungiAssignee: Lubomír Sedlář <lsedlar>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 25CC: dennis, dmach, jrivera
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-02 06:54:01 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:
Embargoed:

Description Jose A. Rivera 2015-03-06 05:12:08 UTC
There is a rather insidious little bug where Pungi will pull in an obsoleted package if said package has a different name from the package which obsoleted it. This is due to the following line in the Pungi code:

https://git.fedorahosted.org/cgit/pungi.git/tree/src/pypungi/__init__.py#n508

Scrolling up a bit, we can see that we're in a function called "get_package_deps", and we're checking if "greedy_method == all" (which is the default!). If so, the method returnNewestByNameArch() is used with the intention of determining what the newest available provider is for a given requirement for each architecture we need to compose.

The problem shows up because that method ALSO distinguishes between providers that have different names, i.e. libfoo and foo-libs, and returns the newest version of each unique name/arch combination it finds. Pungi includes all items returned by returnNewestByNameArch() in the list of packages for the compose.

The solution would probably be to change the use of "yum.YumBase.whatProvides" in the above file to "yum.YumBase.resolveDeps". The latter makes use of the "_compare_providers" method, which is what ends up properly ranking the dependency providers (and thus why this problem never shows up when using yum on the command line). Unfortunately resolveDeps doesn't give return values, so some minor refactoring around it would need to occur.

Comment 1 Jan Kurik 2015-07-15 14:26:34 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 2 Fedora End Of Life 2016-11-24 11:32:20 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Daniel Mach 2016-11-24 11:56:30 UTC
Assigning to Lubomir to review the problem and fix it if still necessary.

Comment 4 Lubomír Sedlář 2016-11-24 13:02:29 UTC
I can't replicate with the details given.

My testcase includes three packages:
dummy-productmd-0.3-1
dummy-python-productmd-1.0-1
  - Obsoletes: dummy-productmd<1.0-1
  - Provides: dummy-productmd=1.0-1
dummy-pdc-1.0-1
  - Requires: dummy-productmd

I specify dummy-pdc as input and expect it should pull in the new version provided by dummy-python-productmd, which is what is happening the the current version.

If I specifically list dummy-productmd as input package, I do indeed get it in the result despite it being obsoleted. However that looks like the correct behaviour since it was actually requested to be included.

Comment 5 Jose A. Rivera 2016-12-19 16:10:13 UTC
You guys took so long to get around to this that not only has the code base completely changed I haven't needed to use pungi for a while so I can't verify if it's even still a problem. :) Feel free to close this bug.