Bug 165151 - RFE: yum multi-lib conflict reports should list archs
RFE: yum multi-lib conflict reports should list archs
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-04 14:02 EDT by Tony Nelson
Modified: 2014-01-21 17:52 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-19 16:03:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tony Nelson 2005-08-04 14:02:49 EDT
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@uibk.ac.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 15:33:10 EDT
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 00:39:40 EDT
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 09:56:28 EDT
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 10:04:06 EDT
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 10:38:09 EDT
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 10:40:20 EDT
conflicts aren't arch-specific.

Comment 7 Tony Nelson 2005-09-30 10:52:44 EDT
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.

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