Bug 168825

Summary: File conflicts between 32bit and 64bit packages
Product: [Fedora] Fedora Reporter: Phil Knirsch <pknirsch>
Component: kdebaseAssignee: Than Ngo <than>
Status: CLOSED CURRENTRELEASE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mgarski, orion, rdieter, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: FC-6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-02-13 17:02:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 228347, 228370, 228371, 228387    

Description Phil Knirsch 2005-09-20 15:08:19 UTC
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 Than Ngo 2007-02-13 17:02:55 UTC
it's fixed in the current FC6

Comment 2 Rex Dieter 2007-02-13 17:05:18 UTC
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 Than Ngo 2007-02-13 19:37:01 UTC
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 18:20:27 UTC
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 19:41:37 UTC
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 21:14:25 UTC
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 21:21:02 UTC
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.