Bug 480685 - fontforge multilib conflict
Summary: fontforge multilib conflict
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: fontforge
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-19 20:13 UTC by Philippe Troin
Modified: 2009-04-24 22:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-24 22:26:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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