Bug 88285 - /usr/X11R6/include/X11/bitmaps in wrong package (perhaps?)
Summary: /usr/X11R6/include/X11/bitmaps in wrong package (perhaps?)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-08 15:42 UTC by Jonathan Peatfield
Modified: 2007-03-27 04:02 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2003-04-19 13:40:39 UTC

Attachments (Terms of Use)

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.

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