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
Those are selinux file context differences, not file conflicts.
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.
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?
A
Er. Why has this been reassigned to me?? I am not the rpm maintainer!
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.
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?
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.
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.