Bug 1659534

Summary: Traceback when non of the possible alternatives can be installed
Product: Red Hat Enterprise Linux 7 Reporter: Honza Horak <hhorak>
Component: yumAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: low    
Version: 7.6CC: james.antill
Target Milestone: rc   
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: 2019-02-12 08:16:49 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 Honza Horak 2018-12-14 15:49:22 UTC
Description of problem:
When yum is asked to install something by a virtual provide or a file, and so yum wants to pick from possible alternatives, but non of the alternatives is install-able due to conflicts, a traceback is printed.

In my reproducer below, I think the problematic case is that mariadb-connector-c requires /etc/my.cnf but the only package that provides it is mysql-libs, that conflicts with mariadb-connector-c.

Version-Release number of selected component (if applicable):
yum-3.4.3-161.el7.noarch

How reproducible:
easy

Steps to Reproduce:
1. yum -y remove mysql-libs
2. yum install https://hhorak.fedorapeople.org/mariadb-connector-c-3.0.5-2.el7.x86_64.rpm
3.

Actual results:
Loaded plugins: product-id, search-disabled-repos, subscription-manager
This system is not registered with an entitlement server. You can use subscription-manager to register.
mariadb-connector-c-3.0.5-2.el7.x86_64.rpm                                                                                                                                                  | 139 kB  00:00:00     
Examining /var/tmp/yum-root-vh8qqq/mariadb-connector-c-3.0.5-2.el7.x86_64.rpm: mariadb-connector-c-3.0.5-2.el7.x86_64
Marking /var/tmp/yum-root-vh8qqq/mariadb-connector-c-3.0.5-2.el7.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package mariadb-connector-c.x86_64 0:3.0.5-2.el7 will be installed
--> Processing Dependency: /etc/my.cnf for package: mariadb-connector-c-3.0.5-2.el7.x86_64
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 375, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 239, in main
    (result, resultmsgs) = base.buildTransaction() 
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1198, in buildTransaction
    (rescode, restring) = self.resolveDeps()
  File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 893, in resolveDeps
    CheckDeps, checkinstalls, checkremoves, missing = self._resolveRequires(errors)
  File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 1025, in _resolveRequires
    (checkdep, missing, errormsgs) = self._processReq(po, dep)
  File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 350, in _processReq
    CheckDeps, missingdep = self._requiringFromTransaction(po, requirement, errormsgs)
  File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 680, in _requiringFromTransaction
    rel=pkg.rel)
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 5280, in update
    availpkgs = self._compare_providers(availpkgs, requiringPo)
  File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 1648, in _compare_providers
    bestnum = max(pkgresults.values())
ValueError: max() arg is an empty sequence


Expected results:
A readable error is printed.

Additional info:
I tried that on a 1minutetip machine, but should be reproducible elsewhere as well.
It's not causing me any troubles, but I wanted to report this for the case it causes troubles to customers and might not have a reproducer.
Feel free to close it if you think this is not worth fixing.

Comment 1 Daniel Mach 2019-02-12 08:16:49 UTC
There is no plan to fix this bug during RHEL 7 life cycle.
If you still consider the issue important, please contact your support representative.