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):
Steps to Reproduce:
1. rpm -e XFree86-devel
Warning: Cannot convert string "flagup" to type Pixmap
Warning: Cannot convert string "flagdown" to type Pixmap
(and the pictures look "wrong").
It working as usual.
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
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.