Bug 165151

Summary:	RFE: yum multi-lib conflict reports should list archs
Product:	[Fedora] Fedora	Reporter:	Tony Nelson <tonynelson>
Component:	yum	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	katzj, nobody+pnasrat
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-04-19 20:03:46 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:

Description Tony Nelson 2005-08-04 18:02:49 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6

Description of problem:
When yum reports a dependency conflict and the archs for the conflicting packages differ, it should list the archs of the conflicting packages.  I think this arises when there are non-exact version matches for multi-lib support of i386 and x86_64.  The present error is quite obscure, and requires either experience or asking someone what it means.

This RFE is prompted by the fedora-list thread "More and more yum depandency problems" at Message-ID: <42EF3A85.3040406.at>.  I'm not using x64 or FC4 myself (yet), but having this feature would benefit me when I do, and would benefit others now.  The actual problem might be with RPM for all I know.

Version-Release number of selected component (if applicable):


How reproducible:
Didn't try

Steps to Reproduce:
1.roughly, have an x64 system
2.using multi-lib support, install i386 and x86_64 versions of same package
3.manage to get versions out of sync somehow
  

Actual Results:  confusing error message about having two of a package installed.

Expected Results:  less confusing message listing arch of each conflicting package, as part of package name and version.

Additional info:

Comment 1 Jeremy Katz 2005-09-21 19:33:10 UTC

Seth -- what do you think about changing everything that prints out a package
name to be name.arch?  I think we probably also want to move this to be part of
the default rpm query output

Comment 2 Seth Vidal 2005-09-30 04:39:40 UTC

in lots of cases we don't have that info being handed back from rpm.

and if we change it in the default rpmq you better announce it heavily b/c it
will break A LOT of scripts.

Comment 3 Tony Nelson 2005-09-30 13:56:28 UTC

The arch info is only needed when there are conflicts already found.  Could RPM
be queried a second time in such cases?  Then there would be no need to change
any default queries, only to add a new query.

Comment 4 Seth Vidal 2005-09-30 14:04:06 UTC

The problem is we can't know what it is.

if I get back foo-1.1-1 from rpm

and we have foo-1.1-1.i386 and foo-1.1-1.x86_64 installed yum has no way of
knowing which it was asking about.

it has to guess.

Comment 5 Tony Nelson 2005-09-30 14:38:09 UTC

Then if yum can't do any better, it should query RPM to find if there are
potential arch conflicts and if so tell the user that the conflict may stem from
incompatible archs.

Comment 6 Seth Vidal 2005-09-30 14:40:20 UTC

conflicts aren't arch-specific.

Comment 7 Tony Nelson 2005-09-30 14:52:44 UTC

Right, when you get a conflict you have to find out more about it to be useful
to the user.  Query RPM to find out if the conflict /could/ be from multiple
archs, if you can't find out if it /is/.  Give the user a clue to work with. 
When a conflict is reported by RPM, get more info about the installed versions
of packages from RPM, including their arch.  If the conflicting packages come in
different archs, tell the user it may be an arch conflict for those packages.