Bug 193046 - rpm does not handle noarch/arch conflicts properly on i386
Summary: rpm does not handle noarch/arch conflicts properly on i386
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-24 19:32 UTC by Orion Poplawski
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-06-26 23:15:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Orion Poplawski 2006-05-24 19:32:37 UTC
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
tetex-latex-3.0-9.FC4
(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):
rpm-4.4.1-23

Comment 1 Jeff Johnson 2006-05-29 12:21:32 UTC
Those are selinux file context differences, not file conflicts.

Comment 2 Jeff Johnson 2006-05-29 12:53:10 UTC
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 16:36:18 UTC
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 20:01:49 UTC
A

Comment 5 Jonathan Underwood 2006-06-26 20:10:44 UTC
Er. Why has this been reassigned to me?? I am not the rpm maintainer!

Comment 6 Jonathan Underwood 2006-06-26 20:20:35 UTC
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 22:28:53 UTC
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 23:15:24 UTC
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 23:39:32 UTC
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.