Bug 1060308

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

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

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?

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

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.

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?

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

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

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

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

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?

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

Hello,
did anyone encounter this issue within last 6 months or can we have this bug closed?