Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1060308 - backport - depsolve: Use requirement instead of calling string_to_prco_tuple
Summary: backport - depsolve: Use requirement instead of calling string_to_prco_tuple
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum
Version: 6.5
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Valentina Mukhamedzhanova
QA Contact: Pavel Stehlik
URL:
Whiteboard:
Depends On:
Blocks: 871829
TreeView+ depends on / blocked
 
Reported: 2014-01-31 18:31 UTC by Douglas Schilling Landgraf
Modified: 2014-12-03 13:19 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-03 13:19:33 UTC


Attachments (Terms of Use)

Description Douglas Schilling Landgraf 2014-01-31 18:31:15 UTC
Description of problem:

Opening this bugzilla to request backport the below patch to EL6.
We faced this bug during release of ovirt 3.3 RC.
more info:
http://lists.ovirt.org/pipermail/users/2014-January/020677.html

Use requirement instead of calling string_to_prco_tuple
http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=1bbf40af8548d2d3fb9deea8844770fccd67a384

Comment 4 Yaniv Bronhaim 2014-02-18 11:38:15 UTC
Reproducer is a package that contains "Provides" and "Obsolete" statements for different (\old) package that contain same files.

for example:
lets say i have package A that requires package B-DEMO
now i have official B (with same content of B-DEMO, but official)

in B spec I would state: 
Obsolete: B-DEMO
Provides: B-DEMO 
which means that now when I install A, without having B-DEMO installed but B, and both available in the set installation repository. the requirement should be filled by B and won't ask for B-DEMO.

With the above bug the actual result is that B fails to provide B-DEMO (the bug) and the requirement in A tries to take B-DEMO and fail on a conflict

Comment 5 Karel Srot 2014-02-18 17:23:01 UTC
Hi Yaniv,
I am unable to reproduce this problem using the steps you have provided.
Could you please take a look at my steps below whether you find any difference?

# rpm -q --provides -p pkgA-1.0-1.noarch.rpm
pkgA = 1.0-1
# rpm -q --provides -p pkgB-1.0-1.noarch.rpm
pkgB-demo  
pkgB = 1.0-1
# rpm -q --obsoletes -p pkgB-1.0-1.noarch.rpm
pkgB-demo  
# rpm -q --provides -p pkgB-demo-1.0-1.noarch.rpm
pkgB-demo = 1.0-1

# rpm -ql -p pkgB-1.0-1.noarch.rpm
/usr/local/pkgB-demo.tar
# rpm -ql -p pkgB-demo-1.0-1.noarch.rpm
/usr/local/pkgB-demo.tar

# yum install pkgA
Loaded plugins: auto-update-debuginfo, rhnplugin
This system is not registered with RHN Classic or RHN Satellite.
You can use rhn_register to register.
RHN Satellite or RHN Classic support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package pkgA.noarch 0:1.0-1 will be installed
--> Processing Dependency: pkgB-demo for package: pkgA-1.0-1.noarch
--> Running transaction check
---> Package pkgB.noarch 0:1.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================
 Package                  Arch                       Version                   Repository                Size
==============================================================================================================
Installing:
 pkgA                     noarch                     1.0-1                     repr                     2.0 k
Installing for dependencies:
 pkgB                     noarch                     1.0-1                     repr                     2.1 k

Transaction Summary
==============================================================================================================
Install       2 Package(s)

Total download size: 4.1 k
Installed size: 0  
Is this ok [y/N]: 
Exiting on user Command

Comment 6 Karel Srot 2014-02-18 17:28:20 UTC
I forgot to add

$ rpm -q --requires -p pkgA-1.0-1.noarch.rpm 
pkgB-demo  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

but I believe that this is obvious from the yum output. Btw, what is the yum version in question?

Comment 7 Yaniv Bronhaim 2014-02-19 07:21:35 UTC
I recall it happened on both yum-3.2.29-40.el6.noarch and yum-3.4.3-128.fc19.noarch

do you have the following line in depsolve.py:
reqtuple = misc.string_to_prco_tuple(needname + str(needflags) + needversion) ?

the bug is about the creation of the require string ^. you need to add specific version requirement I think.

for example:
pkgA requires pkgB-demo >= 1.0

pkgB provides pkgB-demo = 1.0
pkgB Obsolete pkgB-demo <= 1.0

please try and update with the results

Comment 8 Karel Srot 2014-02-19 07:54:21 UTC
Still no success. Could you please attach --provides --requires and --obsoletes of the original rpm files?

$ rpm -q --requires -p pkgA-1.0-1.noarch.rpm 
pkgB-demo >= 1.0
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
$ rpm -q --provides -p pkgB-1.0-1.noarch.rpm 
pkgB-demo = 1.0
pkgB = 1.0-1
$ rpm -q --obsoletes -p pkgB-1.0-1.noarch.rpm 
pkgB-demo <= 1.0

# yum --disablerepo=\* --enablerepo=repr install pkgA
Loaded plugins: auto-update-debuginfo, rhnplugin
This system is not registered with RHN Classic or RHN Satellite.
You can use rhn_register to register.
RHN Satellite or RHN Classic support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package pkgA.noarch 0:1.0-1 will be installed
--> Processing Dependency: pkgB-demo >= 1.0 for package: pkgA-1.0-1.noarch
--> Running transaction check
---> Package pkgB.noarch 0:1.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================ Package                  Arch                       Version                   Repository                Size
================================================================================Installing:
 pkgA                     noarch                     1.0-1                     repr                     1.9 k
Installing for dependencies:
 pkgB                     noarch                     1.0-1                     repr                     2.1 k

Transaction Summary
================================================================================Install       2 Package(s)

Total download size: 4.0 k
Installed size: 0  
Is this ok [y/N]:

tested with yum-3.2.29-40.el6.noarch.

Comment 9 Yaniv Bronhaim 2014-02-19 12:57:39 UTC
You need to have both pkgB and pkgB-demo in the repository, that i think you do.

I'm trying it also but it doesn't occur as happened when we tried in the past with local repository. Althought the bug was reproducible when the packages were on remote fedora repository .. now when we updates the latest vdsm version in koji I can't make it happens. any idea what can be the differences between local and remove fedora repos?

Comment 10 Yaniv Bronhaim 2014-02-19 13:20:15 UTC
we verified the fix [1], and saw it passes the provide check as expected.
the bug was reproducible in all of our stations when the packages were available in fedora repo.

if we can't reproduce it locally, can we at least verify if that fix doesn't introduce any regressions and take it in that case?

[1] http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=1bbf40af8548d2d3fb9deea8844770fccd67a384

Comment 11 Yaniv Bronhaim 2014-02-19 13:25:33 UTC
this is the output that we had:

Package vdsm-python-cpopen is obsoleted by python-cpopen, but obsoleting package does not provide for requirements

Error: Package: vdsm-xmlrpc-4.13.3-2.fc19.noarch (ovirt-3.3.3)
Requires: vdsm-python-cpopen

Available: python-cpopen-1.3-1.fc19.x86_64 (updates)
vdsm-python-cpopen = 4.13.2

Available: vdsm-python-cpopen-4.12.1-2.fc19.i686 (ovirt-stable)
vdsm-python-cpopen = 4.12.1-2.fc19

Available: vdsm-python-cpopen-4.12.1-4.fc19.i686 (ovirt-stable)
vdsm-python-cpopen = 4.12.1-4.fc19

Available: vdsm-python-cpopen-4.13.0-9.fc19.i686 (ovirt-stable)
vdsm-python-cpopen = 4.13.0-9.fc19
Available: vdsm-python-cpopen-4.13.0-11.fc19.i686 (ovirt-stable)
vdsm-python-cpopen = 4.13.0-11.fc19
Available: vdsm-python-cpopen-4.13.2-1.fc19.i686 (ovirt-stable)
vdsm-python-cpopen = 4.13.2-1.fc19
Available: vdsm-python-cpopen-4.13.3-2.fc19.i686 (ovirt-3.3.3)
vdsm-python-cpopen = 4.13.3-2.fc19

when the provide statement was:
rpm -q --provides python-cpopen
python-cpopen = 1.3-1.fc19
python-cpopen(x86-64) = 1.3-1.fc19
vdsm-python-cpopen = 4.14.0

Comment 13 Karel Srot 2014-02-19 13:55:40 UTC
(In reply to Yaniv Bronhaim from comment #10)
> if we can't reproduce it locally, can we at least verify if that fix doesn't
> introduce any regressions and take it in that case?

In general I am not against releasing the fix but it is not easy to verify that it doesn't introduce regressions (when the dependency chains can be complicated).

Can I ask James to provide some justification why the fix is required? Maybe he can help me to reproduce the issue.

Comment 18 Yaniv Bronhaim 2014-02-23 08:02:11 UTC
I understand your concern, we couldn't reproduce it with local repository as I stated. It happened to us (in more than one station) when the same packages (python-cpopen 1.2.3-4 and vdsm 4.13.2) were on same fedora repo. currently I don't have anything further to add except trying to propose packages with the same config to be pushed to fedora. When I have such environment I'll ping this bug

Comment 20 Dan Kenigsberg 2014-02-26 12:11:42 UTC
We've noticed this yum bug on Fedora, and it has blocked our release of ovirt-3.3.3. Fearing that the same bug would block our equivalent rhev-3.3.z release, we've opened this bug.

If my fear materializes, how quickly could a patched yum be released? Can we at least verify that the patched version has no regressions, so that time-to-release is shortened?

Comment 21 Karel Srot 2014-02-26 12:38:24 UTC
(In reply to Dan Kenigsberg from comment #20)
> We've noticed this yum bug on Fedora, and it has blocked our release of
> ovirt-3.3.3. Fearing that the same bug would block our equivalent rhev-3.3.z
> release, we've opened this bug.

I understand. But it is also possible that the problem was caused by the package itself or outdated repo metadata during the update. 
 
> If my fear materializes, how quickly could a patched yum be released? Can we
> at least verify that the patched version has no regressions, so that
> time-to-release is shortened?

Saying that a patch didn't introduce NO regressions into depsolving is difficult simply because depsolving itself could be quite complex. This particular patch already introduced regressions into fedora and therefore I do not want to let it go into RHEL until we have real-life reproducer. So if (once) you can provide me RHEL-6 repo when the problem can be reproduce with RHEL-6 yum I am willing to ack it and test the errata (withing 1 or 2 days). But I want to be sure first what is the culprit and we are really addressing a yum bug.

Comment 32 Karel Srot 2014-08-20 05:37:18 UTC
Hello,
did anyone encounter this issue within last 6 months or can we have this bug closed?


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