Otherwise, you may get the impression that a package conflicts with itself, which is strange.
rpm doesn't give us back the arch
It does if you ask it nicely ...
not in the dep conflict/error output it doesn't. arch is never mentioned.
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).
The above is fixed now in rawhide (rpm-4.4.2.2-6.fc9) 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...
The rpm part is now fixed in rawhide (rpm-4.4.2.2-7.fc9) 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 >= 4.4.2.3 or so)
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.
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.
rpm-4.4.2.2-7.fc8 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'
rpm-4.4.2.2-7.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.