Bug 88285 - /usr/X11R6/include/X11/bitmaps in wrong package (perhaps?)
/usr/X11R6/include/X11/bitmaps in wrong package (perhaps?)
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-08 11:42 EDT by Jonathan Peatfield
Modified: 2007-03-27 00:02 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-19 09:40:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Peatfield 2003-04-08 11:42:52 EDT
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...
Comment 1 Mike A. Harris 2003-04-19 09:40:39 EDT
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.