Bug 349091 - add arch to printed package tuple when displaying conflicts
Summary: add arch to printed package tuple when displaying conflicts
Alias: None
Product: Fedora
Classification: Fedora
Component: yum   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-23 17:16 UTC by Bill Nottingham
Modified: 2014-03-17 03:11 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-12 15:07:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bill Nottingham 2007-10-23 17:16:28 UTC
Otherwise, you may get the impression that a package conflicts with itself,
which is strange.

Comment 1 Jeremy Katz 2007-10-23 18:01:11 UTC
rpm doesn't give us back the arch 

Comment 2 Tom Lane 2007-10-23 21:17:33 UTC
It does if you ask it nicely ...

Comment 3 Seth Vidal 2007-10-23 22:07:22 UTC
not in the dep conflict/error output it doesn't.

arch is never mentioned.

Comment 4 Panu Matilainen 2007-10-24 06:18:13 UTC
Yup, the arch exists in the problem set originally but rpm-python ts.check()
f***s up the rpmProblem->pkgNEVR string while parsing for NEVRA info that only
name is left.

The tuple(s) returned by ts.check() and solve callback don't have arch info and
that can't be changed without breaking compatibility, but the textual problem
string is easy to fix (will do).

Comment 5 Panu Matilainen 2007-10-24 07:40:27 UTC
The above is fixed now in rawhide (rpm- but looking more into
it... it's actually a different problem from the original report which is
present on rpm level too:

[pmatilai@localhost x86_64]$ rpm -U --test conflict-arch-1-1.x86_64.rpm
        file /var/archtest from install of conflict-arch-1-1 conflicts with file
from package conflict-arch-1-1

Fixed upstream now: 
[pmatilai@localhost x86_64]$ ~/repos/rpm/rpmi -U --test conflict-arch-1-1.x86_64.rpm
        file /var/archtest from install of conflict-arch-1-1.x86_64 conflicts
with file from package conflict-arch-1-1.i386

Will patch for Fedora too...

Comment 6 Panu Matilainen 2007-10-24 08:35:08 UTC
The rpm part is now fixed in rawhide (rpm- by using package NEVRA
instead of just NEVR everywhere for all problems. However the problem of
ts.check() tuples not containing arch information is unsolvable in rpm 4.4.x
because of the incompatibility it would introduce.

Right now for yum the options would be:
a) make yum use the problems strings given by rpm instead of generating its own
based on the tuples
b) enhance the python level problem object with methods for retrieving the NEVRA
etc information from there and make yum use those instead of the tuples (but it
cause yum to require rpm >= or so)

Comment 7 Florian Festi 2007-10-24 13:20:58 UTC
I am sorry to disturb your nostalgic discussion, but yum stopped using rpmlib
for the transaction check quite a while ago. Yum's own code has full access to a
information needed. Just pass the conflicting pkg object from _checkConflicts to
.processConflict() to fix that.

Reassigning back to proper component.

Comment 8 Florian Festi 2007-10-24 13:38:29 UTC
For completeness:
For file conflicts (which are not part of the transaction check but are done in
the Transaction Test - after the "Is this ok [y/N]" question) rpmlib is used.
These errors should already be fixed by the rpm changes as they are not returned
with pkg tuples - but this needs be verified.

Comment 9 Fedora Update System 2007-11-13 00:08:37 UTC
rpm- has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update rpm'

Comment 10 Fedora Update System 2007-11-20 18:03:35 UTC
rpm- has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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