Request for volunteers to help track down packages that use /usr/X11R6

[Mike A. Harris]

Mike A. Harris wrote:
[SNIP]
> What's changing specifically:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> X.Org X11 will no longer use the /usr/X11R6 directory hierarchy
> at all.  It uses /usr, and installs files where you'd expect
> them to be found within that heirarchy more or less (although
> it is a bit buggy in this regard currently, that'll be fixed
> prior to X11R7's final release).  The libraries, binaries,
> fonts, config files, data files - everything is moving.
> 
> Along with this upstream X.Org change, there will be a number
> of backward compatibility issues that we'll face, where we
> may need to provide backward compatible symlinks for cases like
> applications hard coding the path to X binaries instead of
> using "which <appname>" and similar.  We'll be keeping an
> eye on such issues and considering where we should provide
> compatibility links.
> 
> 
> What we'd like volunteers to help with:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 1) A lot of existing Fedora Core, Fedora Extras and other 3rd
>    party packages currently install themselves into /usr/X11R6,
>    need to be updated to install themselves in a more
>    appropriate location under /usr, using %{_datadir} and
>    friends in their rpm specfiles.  Volunteers are needed who
>    are willing to take on the task of reporting bugs against
>    the offending packages, and preferably also attaching
>    patches to fix the rpms.
> 
> 2) A number of packages might have shell scripts, .desktop
>    files, or other things with hard coded paths to binaries
>    such as /usr/X11R6/bin/xterm, or to data files, or other
>    files traditionally installed under /usr/X11R6.  Please
>    report bugs against these packages, and where possible,
>    change them to use "which <appname>" instead of hard
>    coding the path to the executable/file directly.  In some
>    cases dynamic solution might not work, so hard code the
>    new path in that case unless there's another appropriate
>    solution apparent.
> 
> 3) If you can personally think of any application or compat
>    problems that might occur when the changeover is made,
>    please report them to me via email in advance, so we can
>    try to find a solution sooner than later.
> 
> 
> This message is being sent out to encourage community
> involvement in the process, and to help weed out problems
> sooner in the development cycle than later on, as there
> is likely to be a fair amount of package churn, so we'd
> like to get things in order far far in advance of
> FC5test1.
> 
> Thanks in advance for any feedback, and also to any
> volunteers who decide to help out.

At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide.  ;o)

We will be finding/fixing anything obvious we find prior to
it hitting rawhide, however if we miss anything I'm sure that
we'll find out after it goes live in rawhide and everyone
suddenly becomes a volunteer.   ;o)

Thanks again.
TTYL