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:
it's fixed in the current FC6
What did you do to "fix" it? I ask mainly because there's apparently quite a few kde-related pkgs with the same problem.
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.
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....
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.
Ah, I get it - KDE ships prebuilt index.cache.bz2 files! So, do we really need to poke all upstreams to do the same?
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.