Description of problem: In the current set of rawhide updates we have $ rpm -qf /usr/bin/texi2pdf tetex-2.0.2-30 texinfo-4.8-1 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-2.1.13-1
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? thanks.
> 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.