Red Hat Bugzilla – Bug 193046
rpm does not handle noarch/arch conflicts properly on i386
Last modified: 2007-11-30 17:11:33 EST
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
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....T. c /usr/share/texmf/tex/latex/preview/prauctex.cfg
Version-Release number of selected component (if applicable):
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?
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.