Description of problem: Install a machine without XFree86-devel, oops no /usr/X11R6/include/X11/bitmaps so some apps can't find their bitmaps to display (e.g. xbiff). Version-Release number of selected component (if applicable): How reproducible: easy Steps to Reproduce: 1. rpm -e XFree86-devel 2. xbiff 3. Actual results: $ xbiff Warning: Cannot convert string "flagup" to type Pixmap Warning: Cannot convert string "flagdown" to type Pixmap (and the pictures look "wrong"). Expected results: It working as usual. Additional info: Of course this is really an XFree86 problem, they chose to hide these things under .../include/X11/ is a pain. Perhaps that directly could be in XFree86-tools or something... I don't expect a fix of course...
I agree that this is a quite dumb thing for an application to depend on. The proper solution would be for the bitmaps to be compiled right into the application itself, or for it to install them into a sane location, preferably one not dictated by X history, but by common sense and modern standards, such as /usr/share/pixmaps or similar. I've had a quick peek at the xbiff source code and nothing jumps our at me as a simple quick way of fixing the problem, and since it is a really trivial issue, I'd rather not waste any development time on it. With the current packaging, the first thing one might consider doing is adding a "Requires: XFree86-devel" to the package with xbiff in it. That is ugly however and would force pretty much every user to install the XFree86-devel package just so that xbiff works. I would consider this solution to be much more of a bad thing than xbiff being broken. Due to the trivial nature of this issue, there are 3 solutions which are sensible: 1) Leave things as-is, and you can file a bug report at http://bugs.xfree86.org asking them to make applications not require developmental files in include paths at runtime. 2) Remove xbiff from our packaging and just not distribute it 3) Wait for someone else to supply a patch to xbiff which solves the problem in a sensible way, then consider applying it in the future. I'm choosing #1 for now, and closing as WONTFIX, but #2 is a close second place. ;o) If you or someone else wants to come up with a decent patch for #3, or file upstream, feel free to reopen this with a patch attached in the future.