Bug 193046 - rpm does not handle noarch/arch conflicts properly on i386
rpm does not handle noarch/arch conflicts properly on i386
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-05-24 15:32 EDT by Orion Poplawski
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-26 19:15:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2006-05-24 15:32:37 EDT
Description of problem:

tetex-preview-11.82-10.fc4.noarch was just released in extras.  It has some
files that conflict with tetex-latex-3.0-9.FC4.<arch>.  On x86_64 the conflicts
are flagged:

file /usr/share/texmf/tex/latex/preview/prauctex.cfg
from install of tetex-preview-11.82-10.fc4 conflicts with file from package
(and so on...)

However, on i386, the tetex-preview is installed without error or warning, but now:

# rpm -V tetex-latex
S.5....TC   /usr/share/texmf-var/web2c/latex.fmt
S.5....TC   /usr/share/texmf-var/web2c/pdflatex.fmt
S.5....T. c /usr/share/texmf/tex/latex/preview/prauctex.cfg
S.5....T.   /usr/share/texmf/tex/latex/preview/prauctex.def
S.5....T.   /usr/share/texmf/tex/latex/preview/prcounters.def
S.5....T.   /usr/share/texmf/tex/latex/preview/preview.sty
S.5....T.   /usr/share/texmf/tex/latex/preview/prfootnotes.def
S.5....T.   /usr/share/texmf/tex/latex/preview/prlyx.def
S.5....T.   /usr/share/texmf/tex/latex/preview/prshowbox.def
S.5....T.   /usr/share/texmf/tex/latex/preview/prshowlabels.def
S.5....T.   /usr/share/texmf/tex/latex/preview/prtightpage.def
S.5....T.   /usr/share/texmf/tex/latex/preview/prtracingall.def

Version-Release number of selected component (if applicable):
Comment 1 Jeff Johnson 2006-05-29 08:21:32 EDT
Those are selinux file context differences, not file conflicts.
Comment 2 Jeff Johnson 2006-05-29 08:53:10 EDT
The i386 and x86_64 packages are the problem. The content on the path included in both packages either 
needs to be identical or moved to a different, per-arch, path.
Comment 3 Orion Poplawski 2006-06-05 12:36:18 EDT
I don't quite understand.  It appears that on the i386 machine, rpm allowed the
installation of a noarch package (tetex-preview) that stomped on files owned by
an arch specific package (tetex-latex), leaving that package broken (rpm -V
tetex-latex shows files that don't match it's rpm database).  Isn't this a problem?
Comment 4 Paul Nasrat 2006-06-26 16:01:49 EDT
Comment 5 Jonathan Underwood 2006-06-26 16:10:44 EDT
Er. Why has this been reassigned to me?? I am not the rpm maintainer!
Comment 6 Jonathan Underwood 2006-06-26 16:20:35 EDT
Paul, please do not reassign the bug without stating why you are doing so. This
is clearly a problem with rpm, for which the conflict (now resolved) between the
emacs-auctex and tetex packages was an example.
Comment 7 Jonathan Underwood 2006-06-26 18:28:53 EDT
Referring to Comment #2 - the files in question are not binary files, they are
text files - why would they need per-arch directories? I feel sure we're missing
something important here - Jeff, perhaps you could expand your explanation a little?
Comment 8 Paul Nasrat 2006-06-26 19:15:24 EDT
As far as I am aware packages in Extras should not conflict with core, hence it
being a packaging issue.  If this is resolved in FC4 thanks for that - closing.
Comment 9 Jonathan Underwood 2006-06-26 19:39:32 EDT
Paul, I think you're missing the point. There was a packaging problem, such that
two packages had the same files in. That is now rectified. However, in the
process of spotting this packaging problem, we noticed that RPM failed to spot
the conflict and installed files from one package over the files from the other
- RPM is not supposed to allow this to happen, as far as I understand. So, this
revealed a bug in RPM. Please re-read Orion's bug report. 

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