The modular tree puts the libX11 locale data files in /usr/lib/X11/locale, however these files are architecture independent data files, which should be installed in /usr/share on FHS compliant systems. The default location for these files for FHS compliant Linux (or other) installations should be /usr/share/X11/locale however it probably makes sense that this should be overrideable via ./configure options as well.
How is configure supposed to know if your Linux system is FHS compliant? Sounds like it needs a --enable-fhs-paths flag for those so inclined.
Simple, it should install "data" files into "datadir" on all platforms. The platform then tells configure what "datadir" is and everything works properly on all platforms. FHS compliant systems would pass: ./configure --datadir=/usr/share --libdir=/usr/lib etc. to ./configure, and non-FHS compliant systems would pass whatever the directory is that they want --datadir to use. The default if nothing is specified, can be anything at all. On Red Hat systems, we pass configure the directory names of every single ./configure option in order to specify where things should go, only the modular Xorg does not honour these configure options properly. To recap, if you just type "./configure", configure should default to whatever it wants for each of the directory options. That can be "traditional X locations", "/usr/X11R7", or whatever X.Org thinks is appropriate. When you tell ./configure explicitly however that: --prefix=/usr --datadir=/usr/share --libdir=/usr/lib etc., then it should honour this, and put the "data" files in the "datadir". No --enable-fhs-mode is necessary nor is it desired. The FHS complaint operating system, passes ./configure the FHS compliant locations for the types of files via --<foo>dir so that things go to the expected place. Xorg is just not honouring the usage of these options properly, however some packages have gotten cleaned up between RC0 and RC1, and more in RC2. Intentionally breaking the usage of --datadir or not using it just makes life incredibly more difficult for all of the distributions out there that expect standard GNU ./configure options to work as expected.
To give a more specific example... Install architecture neutral "data" into for example: fontdir=$(datadir)/X11/fonts localedir=$(datadir)/X11/locale install rgb.txt into $(datadir) and have the things that look for it, look in datadir. Now, let Xorg decide what the default will be for datadir, etc., and you don't have to care what FHS is more or less. Set datadir to /usr/lib for "official Xorg" default, or for non-FHS compliant systems. The FHS complaint systems don't use the default anyway, and specify already that --datadir=/usr/share. Everything just magically works for everyone, FHS complaint or not.
... where "complaint" should have been "compliant"... nice spelling on me today.
Created attachment 3856 [details] [review] patch to separate localedir and localelibdir handling here's the patch I wrote towards this end for Ubuntu. we've been using it for a while with no problems.
Comment on attachment 3856 [details] [review] patch to separate localedir and localelibdir handling approval requested, as this is a (legitimate, IMO) 6.9/7.0 blocker
I just implemented my own fix before checking bugzilla. ;o/ Mine is the same as yours for the datadir, but does not handle the i18n modules as we don't build them by default. I've looked at your patch and it seems sane to me. It sounds like it has gotten testing via Ubuntu, so I believe this should be fixed for X11R7 as well. Relteam: Please approve this, and commit to CVS before RC3 if possible. Note: To anyone applying the patch to RC2 packages, you'll need to run "aclocal;automake;autoconf" to activate the changes. HTH
autoreconf is a better idea, imo
Comment on attachment 3856 [details] [review] patch to separate localedir and localelibdir handling should definitely get done, but is too complex for 7.0. denied for now.
Added patch keyword
-> 7.2
committed to git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.