Bug 168825 - File conflicts between 32bit and 64bit packages
File conflicts between 32bit and 64bit packages
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kdebase (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
Ben Levenson
:
Depends On:
Blocks: 228347 228370 228371 228387
  Show dependency treegraph
 
Reported: 2005-09-20 11:08 EDT by Phil Knirsch
Modified: 2015-03-04 20:15 EST (History)
4 users (show)

See Also:
Fixed In Version: FC-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-13 12:02:55 EST
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 Phil Knirsch 2005-09-20 11:08:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050818 Fedora/1.1-0.2.7.deerpark.alpha2.1 Firefox/1.0+

Description of problem:
File conflicts exists between the installed 32bit and 64bit packages:

Error: kdebase-6:3.4.2-4.i386 file conflicts with:
Error:  '/usr/share/doc/HTML/en/kdm/index.cache.bz2' <=> kdebase-6:3.4.2-4.x86_64


Version-Release number of selected component (if applicable):
kdebase-6:3.4.2-4

How reproducible:
Always

Steps to Reproduce:
1. Use a file conflict enabled rpm to install both 32bit and 64bit versions of this package
2.
3.
  

Actual Results:  See listed file conflicts in description

Expected Results:  No file conflicts

Additional info:
Comment 1 Ngo Than 2007-02-13 12:02:55 EST
it's fixed in the current FC6
Comment 2 Rex Dieter 2007-02-13 12:05:18 EST
What did you do to "fix" it?  I ask mainly because there's apparently quite a
few kde-related pkgs with the same problem.
Comment 3 Ngo Than 2007-02-13 14:37:01 EST
it's fixed in the kde upstream. I suppose they have got rid of the path lib64 or
arch from index file. It should be simple fix.
Comment 4 Orion Poplawski 2007-02-14 13:20:27 EST
Looks like it is the "<a name="id2419014">" entries that are generated that are
different.

Current kdebase-3.5.6/doc/kcontrol/kdm/Makefile.in rule is basically:

index.cache.bz2: $(srcdir)/index.docbook $(KDE_XSL_STYLESHEET) index.docbook
        $(MEINPROC) --check --cache index.cache.bz2 $(srcdir)/index.docbook

Doesn't look like this has changed.  *Maybe* meinproc has changed to produce
reproducible ids.  Looking into it further....
Comment 5 Orion Poplawski 2007-02-14 14:41:37 EST
I'm not having any luck with this.  With my kde packages, kdesvn and kompose,
every time I build index.cache.bz2 with meinproc I get new id entries.  So at
this point I can only think that is luck of some part of the build system that
ever gets these to come out the same.  I have a file conflict bug filed against
kdesvn but not kompose.  I suppose I could rebuild kdesvn to see what happens,
but that just seems like voodoo.
Comment 6 Orion Poplawski 2007-02-14 16:14:25 EST
Ah, I get it - KDE ships prebuilt index.cache.bz2 files!  So, do we really need
to poke all upstreams to do the same?
Comment 7 Orion Poplawski 2007-02-14 16:21:02 EST
Looks like generate-id in libxslt uses the memory address of the node to create
the unique node it.  On systems with VM randomization, this will essentially be
random from run to run.  Without it, it might be deterministic.

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