Bug 480685

Summary:	fontforge multilib conflict
Product:	[Fedora] Fedora	Reporter:	Philippe Troin <phil>
Component:	fontforge	Assignee:	Kevin Fenzi <kevin>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	10	CC:	fonts-bugs, kevin, roozbeh
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-04-24 22:26:24 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:

Description Philippe Troin 2009-01-19 20:13:50 UTC

Description of problem:

yum install fontforge.i386 fontforge.x86_64

yields:

Transaction Check Error:
  file /usr/share/fontforge/python/excepthook.pyc from install of fontforge-20080828-1.fc10.i386 conflicts with file from package fontforge-20080828-1.fc10.x86_64
  file /usr/share/fontforge/python/excepthook.pyo from install of fontforge-20080828-1.fc10.i386 conflicts with file from package fontforge-20080828-1.fc10.x86_64

Version-Release number of selected component (if applicable):
fontforge-20080828-1.fc10

Comment 1 Kevin Fenzi 2009-01-21 16:40:13 UTC

Well, I'm not sure there is an easy way around this one. ;( 
Those are python compiled files that are made during build. 

Of course the x86_64 and i386 builds happen at slightly different times, so the generated files differ at least in timestamps. ;( 

Possible hacks: 

- Move them to the python arch directory so they are different per build. 
Thats kinda bad though as they are really the same files, so it would be duplication. 

- Set the timestamps on them from something else (the source exepthook.py?)
This would be a bit misleading however. 

- Drop the python file entirely for now. This is bad because this file runs the exception hook for gui sessions, so users can see when they get an exception instead of it going to stderr. ;( 

I'm open to other ideas...

Comment 2 Philippe Troin 2009-01-21 18:56:46 UTC

Well, why are python files under /usr/share?

All python packages are generally installed under /usr/lib{,64}/python.
Moving these files there should fix the problem.

Alternately, preserving the timestamp while copying the .py file that is the source of the py[co] should work as well.  I don't see how that would be misleading...

Comment 3 Kevin Fenzi 2009-04-02 06:18:13 UTC

I'm not entirely sure why upstream wants to install them there. :( 

In any case I have set it to preserve timestamp for now, and that solves this issue. 
I just noticed that you reported this against f10. Did you need/want a f10 update to fix this? 
Or is a rawhide update ok? 

We try and avoid fontforge updates in stable releases in general since it's used to build fonts and we don't want to prevent any of them from building for some reason, but we have been considering an update for f10 for a while.

Comment 4 Philippe Troin 2009-04-24 19:07:06 UTC

An F10 update would be nice, but is not stricly necessary.

Comment 5 Kevin Fenzi 2009-04-24 22:26:24 UTC

Well, I raised the subject, but it didn't seem to get much interest. ;( 

I guess I would say lets go ahead and close this now. If a f10 update happens, I will be sure and get these changes in that build. 

Thanks for the bug report and info. 

Feel free to reopen this or file a new bug if you spot anything further.