Bug 147273

Summary: yum architecture dependent behaviour - conflicting files missed or not
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: rpmAssignee: Jeremy Katz <katzj>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: jbj, katzj
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-27 03:29:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michal Jaegermann 2005-02-06 00:12:07 UTC 
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
Comment 1 Seth Vidal 2005-02-06 06:31:16 UTC 
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
Comment 2 Jeff Johnson 2005-08-27 03:29:09 UTC 
Conflicts is conflicts, even if comments.
Comment 3 Michal Jaegermann 2005-08-27 16:41:08 UTC 
Agreed that conflicts are confilcts but the real question was why a reaction
of yum to these changes with a machine architecture.
Comment 4 Seth Vidal 2005-08-27 22:14:34 UTC 
'reaction of yum'?

I don't understand what you mean there.
Comment 5 Michal Jaegermann 2005-08-28 00:07:11 UTC 
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).
Comment 6 Seth Vidal 2005-08-28 00:09:57 UTC 
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.
Comment 7 Michal Jaegermann 2005-08-28 16:56:56 UTC 
> 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.