> Well, I updated Xcontrib last night (in response to a different bug
> report) such that it doesn't use /usr/X11R6/include/bitmaps, which was
> an error, instead it uses /usr/X11R6/include/X11/bitmaps.
Thanks. So now xviewg is the only package which uses the incorrect
/usr/X11R6/include/bitmaps location; I've just filed a bug report.
> Note that:
>
> $ ls -al /usr/include/X11
> lrwxrwxrwx 1 root root 20 Sep 23 09:31 /usr/include/X11 ->
> ../X11R6/include/X11
>
> so this is the same as /usr/include/X11/bitmaps; fvwm would be well
> suited to pick one of
> /usr/X11R6/include/X11/bitmaps
> /usr/include/X11/bitmaps
> (and probably the latter, since it is more generic) since they will be
> the exact same thing on a working debian system.
Of course; see policy section 5.8.
> Note that these bitmaps *do* belong under /usr/include, because they
> are really C include files: they have #define's for width and height,
> and then an array of data. More importantly, X based programs already
> have the convention of doing #include <bitmaps/rdblarrow> and getting
> the appropriate bitmap at compile time, if they want it... so don't
> expect that path to go away.
Well, maybe. They are, indeed, written as C include files, but that
does not make them C include files: programs do not tend to say things
like:
#include <X11/bitmap/Down>
but instead things more like:
XCreateBitmapFromData(...)
XCreatePixmapFromBitmapData(...)
And they can be parsed and used without X.
> As a result of that upload, my system no longer has anything at all in
> /usr/X11r6/include/bitmaps, so I think we've just achieved a big chunk
> of your proposal #2...
Just xviewg to go....
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
