Bug 88285

Summary: /usr/X11R6/include/X11/bitmaps in wrong package (perhaps?)
Product: [Retired] Red Hat Linux Reporter: Jonathan Peatfield <j.s.peatfield>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: low    
Version: 8.0Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-04-19 13:40:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jonathan Peatfield 2003-04-08 15:42:52 UTC
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:


Steps to Reproduce:
1. rpm -e XFree86-devel
2. xbiff
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...

Comment 1 Mike A. Harris 2003-04-19 13:40:39 UTC
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.