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-188.8.131.52-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-184.108.40.206-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 >= 220.127.116.11 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 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-18.104.22.168-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-22.214.171.124-7.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.