Bug 147273 - yum architecture dependent behaviour - conflicting files missed or not
yum architecture dependent behaviour - conflicting files missed or not
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-05 19:12 EST by Michal Jaegermann
Modified: 2014-01-21 17:51 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-26 23:29:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2005-02-05 19:12:07 EST
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 01:31:16 EST
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-26 23:29:09 EDT
Conflicts is conflicts, even if comments.
Comment 3 Michal Jaegermann 2005-08-27 12:41:08 EDT
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 18:14:34 EDT
'reaction of yum'?

I don't understand what you mean there.
Comment 5 Michal Jaegermann 2005-08-27 20:07:11 EDT
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-27 20:09:57 EDT
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 12:56:56 EDT
> 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. 

Note You need to log in before you can comment on or make changes to this bug.