Red Hat Bugzilla – Bug 147273
yum architecture dependent behaviour - conflicting files missed or not
Last modified: 2014-01-21 17:51:15 EST
Description of problem:
In the current set of rawhide updates we have
$ rpm -qf /usr/bin/texi2pdf
with these two files slightly different:
$ rpm -qlvf /usr/bin/texi2pdf | sed -n /bin.texi2pdf/s'/.*t *//p'
538 Jan 19 03:33 /usr/bin/texi2pdf
660 Feb 3 10:09 /usr/bin/texi2pdf
So far so good, but on x86_64 yum asked to update to texinfo-4.8-1
complains about file conflicts and bails out while in the same
situation on i386, i.e. updating from texinfo-4.7-6 while tetex
packages do not change, the same version of yum goes ahead with
the whole transaction and finishes without a peep.
Why this difference? Conflicting files are actually shell scripts
and are the same for both architectures (and a discrepancy in sizes
above is caused, on the top of everything, only by a comment).
Version-Release number of selected component (if applicable):
yum doesn't look at files for conflicts. That's something rpm does in
the transaction check. If it doesn't report them then yum won't complain.
This isn't an issue yum can really affect.
Refiling as rpm
Conflicts is conflicts, even if comments.
Agreed that conflicts are confilcts but the real question was why a reaction
of yum to these changes with a machine architecture.
'reaction of yum'?
I don't understand what you mean there.
I mean exactly what was written in the original report. Let's try again...
With tetex and texinfo packages installed on i386 and x86_64 installations
a yum update with the same versions of packages ended up with a conflict
reported on x86_64 but NOT reported on x86. This discrepancy left me
scratching my head as corresponding texi2pdf scripts were not architecture
dependent (not very surprising).
are the files different in the x86_64 and not in the i386 version?
Your report isn't very clear as how to replicate the problem. Could you please
describe what you do to cause it to occur?
> are the files different in the x86_64 and not in the i386 version?
Of course not. The files in questions are scripts, so there was nothing
to compile, and all packages were build from the same sources. In case
of doubts I did check (at the time I wrote the original report) that these
scripts were indeed the same before and after updates.
> Could you please describe what you do to cause it to occur?
Well, I run basically 'yum update' and on one installation I was greeted
with a conflict notification and on another, in what it looked like the
same situation, everything was happily updated. I forced an update using
rpm where I had to.
I am afraid that from times of the original report versions of yum, rpm
and packages in question changed few times so this is not something which
is reproducible on demand.