Bug 127441

Summary: up2date reports 'conflicts' dep as a 'requires' dep
Product: [Retired] Red Hat Network Reporter: Daniel BerrangĂ© <berrange>
Component: RHN/Web SiteAssignee: Shannon Hughes <shughes>
Status: CLOSED ERRATA QA Contact: Beth Nackashi <bnackash>
Severity: medium Docs Contact:
Priority: medium    
Version: rhn370CC: barryn, mspevack, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-712 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-28 17:09:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 155571, 156320    

Description Daniel Berrangé 2004-07-08 09:45:06 UTC
Description of problem:
The following versions are installed locally:

[root@xldn0290nap root]# rpm -q glibc glibc-utils shadow-utils glibc-
common
glibc-2.3.2-95.6
glibc-utils-2.3.2-95.6
shadow-utils-4.0.3-15
glibc-common-2.3.2-95.6
[root@xldn0290nap root]# 


Now, running up2date against our satellite server indicates two 
pending updates:

Name             Version        Rel     
---------------------------------------
glibc            2.3.2          95.20               i686  
glibc-common     2.3.2          95.20               i386  


This new version of glibc has a conflict on shadow-utils:

root# rpm -qp --conflicts glibc-2.3.2-95.20.i686.rpm 
rpm <= 4.0-0.65
glibc-devel < 2.2.3
shadow-utils < 2:4.0.3-20
root#

However, when running up2date to pull down the glibc update it 
reports:

Unresolvable chain of dependencies:
glibc-2.3.2-95.20              requires shadow-utils < 2:4.0.3-20
glibc-utils-2.3.2-95.6         requires glibc = 2.3.2-95.6

So, it is reporting the 'conflict' on shadow-utils, as a requirement!


NB. Yes, we forgot to upload the new shadow-utils package to our 
satellite server, when uploading the new glibc, but irrespective the 
error message reporting should know the difference between a conflict 
& a requirement


Version-Release number of selected component (if applicable):
up2date-4.2.5-1 (RHEL3, U1)

How reproducible:
ALWAYS

Steps to Reproduce:
1. Populate a satellite server with RHEL 3, Update 1.
2. Install a machine with RHEL 3, Update 1
3. Upload glibc & glibc-common = 2.3.2-95.20 to RHN
4. Run up2date -u
  
Actual results:
Unresolvable chain of dependencies:
glibc-2.3.2-95.20              requires shadow-utils < 2:4.0.3-20
glibc-utils-2.3.2-95.6         requires glibc = 2.3.2-95.6


Expected results:
Unresolvable chain of dependencies:
glibc-2.3.2-95.20              conflicts shadow-utils < 2:4.0.3-20
glibc-utils-2.3.2-95.6         requires glibc = 2.3.2-95.6


Additional info:

Comment 1 Adrian Likins 2005-02-16 19:28:51 UTC
this should be fixed in rhel4 up2date

Comment 2 Daniel Berrangé 2005-04-14 16:44:49 UTC
Re-opening because this bug was reported against RHEL-3.

Comment 4 Adrian Likins 2005-04-19 18:38:06 UTC
The plan for the next RHEL3 is to use the same branch as for rhel4
(up2date-4.4.x) so it should be available for RHEL3.

Comment 6 Debbie McGrath 2005-06-08 14:20:14 UTC
This bug is considered MustFix for RHEL 3 U6 by RHN Engineering.

Comment 11 Beth Nackashi 2005-07-01 14:04:17 UTC
can this be tested with satellite running rhel 4 and client running rhel 3? 
does it matter?  also I need a test plan .... 

Comment 12 Adrian Likins 2005-07-07 18:15:02 UTC
test plan

easiest way to test this is to attempt to reproduce the conditions mentioned
in the original bug report. But thats a fairly involved setup. 

Another more generic approach is to create a test package that conflicts with
something that will always be installed on a test system (say package
"this-conflicts-with-glibc" with a Conflicts: glibc), and populate a test channel
with this. Then subscribe the test box to the test channel and:

up2date this-conflicts-with-glibc

It will fail to install, but should give correct error message about it being
because of a package conflicts, not an unresolved depenency.

The bug was that on package conflicts or unresolved deps, it would use the error
string format for unresolved deps, instead of a less confusing one about
conflicts. So you just need to verify the right error is shown in the case of 
package conflicts.

Comment 13 Beth Nackashi 2005-07-10 18:09:20 UTC
Retested with rhn-apache/httpd conflict.  The rhn-apache install failed, but for
the wrong reason.  It should say "conflicts with" rather than "needs":

Summary:  	Package Install scheduled by bnackash
Details: 	This action will be executed after 2005-07-10 13:58:26 EDT.

This action's status is: Failed.
The client picked up this action on 2005-07-10 13:58:37 EDT.
The client completed this action on 2005-07-10 13:58:43 EDT.
Client execution returned "Failed: packages requested raised dependency
problems" (code 18)
Packages Scheduled:

    * rhn-apache-1.3.27-11.rhn.rhel3

Dependency errors encountered:

    * rhn-apache-1.3.27-11.rhn.rhel3 needs httpd


See also notes from 133541.

Comment 14 Adrian Likins 2005-07-11 19:43:03 UTC
what happens when you try this with the commandline client?

Comment 15 Beth Nackashi 2005-07-11 20:34:28 UTC
It looks correct from the command line.  This is starting to look kinda similar
to 162954.

[root@rlx-3-04 tmp]# rhn_check -vvv
D: check_action {'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>pac
kages.update</methodName>\n<params>\n<param>\n<value><array><data>\n<value><arra
y><data>\n<value><string>httpd</string></value>\n<value><string>2.0.52</string><
/value>\n<value><string>12.ent</string></value>\n<value><string></string></value
>\n</data></array></value>\n</data></array></value>\n</param>\n</params>\n</meth
odCall>\n", 'version': 2, 'id': 24285431}
D: logininfo: {'X-RHN-Server-Id': 1005476363, 'X-RHN-Auth-Server-Time': '1121113
721.14', 'X-RHN-Auth': 'JzqAPEXEarNlQTBb3rfwqQ==', 'X-RHN-Auth-Channels': [['rhe
l-i386-as-4', '20050711161017', '1', '1']], 'X-RHN-Auth-User-Id': '', 'X-RHN-Aut
h-Expire-Offset': '3600.0'}
D: handle_action {'action': "<?xml version='1.0'?>\n<methodCall>\n<methodName>pa
ckages.update</methodName>\n<params>\n<param>\n<value><array><data>\n<value><arr
ay><data>\n<value><string>httpd</string></value>\n<value><string>2.0.52</string>
</value>\n<value><string>12.ent</string></value>\n<value><string></string></valu
e>\n</data></array></value>\n</data></array></value>\n</param>\n</params>\n</met
hodCall>\n", 'version': 2, 'id': 24285431}
D: handle_action actionid = 24285431, version = 2
packages.update ([['httpd', '2.0.52', '12.ent', '']],)
D: do_call packages.update ([['httpd', '2.0.52', '12.ent', '']],)
D: Called update_packages [['httpd', '2.0.52', '12.ent', '']]
D: availablePackageList::channels: <up2date_client.rhnChannel.rhnChannelList ins
tance at 0xb7adedec>
D: listPackages Fetched via: get
D: obsoletesList::channels: <up2date_client.rhnChannel.rhnChannelList instance
at 0xb7adedec>
D: getObsoletes Fetched via: get
D: archscore 4

Name                                    Version        Rel     
----------------------------------------------------------
httpd                                   2.0.52         12.ent            i386  
No advisory information available


D: Called dryRun [['httpd', '2.0.52', '12.ent', '', 'i386', '899244',
'rhel-i386-as-4']]
D: obsoletesList::channels: <up2date_client.rhnChannel.rhnChannelList instance
at 0xb7adedec>
D: getObsoletes Fetched via: diskcache
D: add instance class name up2date
D: Removing package (['kernel', '2.6.9', '11.EL', '', 'i686', '10090698',
'rhel-i386-as-4'], 'Pkg name/pattern')
D: Removing package (['kernel-devel', '2.6.9', '11.EL', '', 'i686', '3746449',
'rhel-i386-as-4'], 'Pkg name/pattern')
D: Removing package (['kernel-doc', '2.6.9', '11.EL', '', 'noarch', '2096141',
'rhel-i386-as-4'], 'Pkg name/pattern')
D: Removing package (['kernel-hugemem', '2.6.9', '11.EL', '', 'i686', '9648914',
'rhel-i386-as-4'], 'Pkg name/pattern')
D: Removing package (['kernel-hugemem-devel', '2.6.9', '11.EL', '', 'i686',
'3769625', 'rhel-i386-as-4'], 'Pkg name/pattern')
D: Removing package (['kernel-smp', '2.6.9', '11.EL', '', 'i686', '9760225',
'rhel-i386-as-4'], 'Pkg name/pattern')
D: Removing package (['kernel-smp-devel', '2.6.9', '11.EL', '', 'i686',
'3760154', 'rhel-i386-as-4'], 'Pkg name/pattern')
D: Removing package (['kernel-utils', '2.4', '13.1.66', '1', 'i386', '556259',
'rhel-i386-as-4'], 'Pkg name/pattern')
D: Candidates for the selected list: [['httpd', '2.0.52', '12.ent', '', 'i386',
'899244', 'rhel-i386-as-4']]
D: Adding to transaction set ['httpd', '2.0.52', '12.ent', '', 'i386', '899244',
'rhel-i386-as-4']
D: Checking for dependencies
D: RPM returned 3 deps.
D: Processing dependency (('httpd', '2.0.52', '12.ent'), ('httpd-suexec', None),
0, None, 0)
D: Processing dependency (('httpd', '2.0.52', '12.ent'), ('libaprutil-0.so.0',
None), 0, None, 0)
D: Processing dependency (('rhn-apache', '1.3.27', '20.rhn.rhel4'), ('httpd',
None), 0, None, 1)
D: Dependencies: [('httpd', 'httpd-suexec'), ('httpd', 'libaprutil-0.so.0')]
D: Dep ['httpd-suexec', 'libaprutil-0.so.0'] Fetched via: [['httpd-suexec',
'2.0.52', '12.ent', '', 'i386', '26273', 'rhel-i386-as-4'], ['apr-util',
'0.9.4', '17', '', 'i386', '52240', 'rhel-i386-as-4']]
D: Got back response: [['httpd-suexec', '2.0.52', '12.ent', '', 'i386', '26273',
'rhel-i386-as-4'], ['apr-util', '0.9.4', '17', '', 'i386', '52240',
'rhel-i386-as-4']]
D: Candidates for the selected list: [['apr-util', '0.9.4', '17', '', 'i386',
'52240', 'rhel-i386-as-4'], ['httpd-suexec', '2.0.52', '12.ent', '', 'i386',
'26273', 'rhel-i386-as-4']]
D: Adding to transaction set ['apr-util', '0.9.4', '17', '', 'i386', '52240',
'rhel-i386-as-4']
D: Adding to transaction set ['httpd-suexec', '2.0.52', '12.ent', '', 'i386',
'26273', 'rhel-i386-as-4']
D: Conflicts: [('rhn-apache', 'httpd')]
D: Candidates for the selected list: []
D: Checking for dependencies
D: RPM returned 1 deps.
D: Processing dependency (('rhn-apache', '1.3.27', '20.rhn.rhel4'), ('httpd',
None), 0, None, 1)
D: Conflicts: [('rhn-apache', 'httpd')]
D: Candidates for the selected list: []
D: Sending back response (18, 'Failed: packages requested raised dependency
problems', {'failed_deps': ((('rhn-apache', '1.3.27', '20.rhn.rhel4'), ('httpd',
''), 0, '', 1),), 'version': '0', 'name': 'packages.update.failed_deps'})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: local action status:  (0, 'rpm database not modified since last update (or
package list recently updated)', {})




Comment 17 Beth Nackashi 2005-08-05 17:30:31 UTC
I don't see any comments from Adrian, so I'm not sure if this bug should really
be in ON_QA state.

Comment 18 Adrian Likins 2005-08-05 17:50:59 UTC
client looks correct, but website is still wrong. Probably need to
reassign this to the website

Comment 19 Beth Nackashi 2005-08-25 00:10:28 UTC
verified -- web UI now has correct text:

Dependency errors encountered:

    * rhn-apache-1.3.27-11.rhn.rhel3 conflicts with httpd

Comment 21 Red Hat Bugzilla 2005-09-28 17:09:27 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-712.html