Convenience /etc/X11 symlinks point the other way round

[alexander@…]

​http://www.linuxfromscratch.org/blfs/view/svn/x/x-setup.html says:

As a convenience, Xorg-7.2 users should populate the /etc/X11 directory with symlinks to various configuration directories that were located in /etc/X11 with previous versions of Xorg. This step is not needed for XFree86 users. Execute the following commands as the root user:

mkdir $XORG_PREFIX/share/X11/twm &&
ln -svt /etc/X11 \
    $XORG_PREFIX/lib/X11/{fs,lbxproxy,proxymngr,rstart} \
    $XORG_PREFIX/lib/X11/{xdm,xinit,xserver,xsm} \
    $XORG_PREFIX/share/X11/{app-defaults,twm,xkb}

I.e., it states that configuration files are not in /etc. This is a direct violation of FHS. The files should really live in /etc/X11, and $XORG_PREFIX/share/X11/{app-defaults,...} should be symlinks to /etc/X11/{app-defaults,...}

OTOH, in Debian, the configuration files are in /etc/X11, and the abovementioned symlinks do not exist. I should examine their way of building Xorg.

[alexander@…]

Debian patches TWM:

Index: src/Makefile.am
===================================================================
--- src/Makefile.am.orig	2007-06-08 00:59:37.000000000 +0200
+++ src/Makefile.am	2007-06-08 01:00:37.000000000 +0200
@@ -24,11 +24,11 @@
 
 bin_PROGRAMS = twm
 
-rcdir = ${datadir}/X11/twm
+rcdir = ${sysconfdir}/X11/twm
 dist_rc_DATA = system.twmrc
 
 twm_CFLAGS = $(TWM_CFLAGS) -DXVENDORNAME=\"The\ X.Org\ Foundation\" -DXORG_RELEASE=\"Release\ (VERSION)\" -D_BSD_SOURCE
-twm_CFLAGS += -DSYSTEM_INIT_FILE=\"${datadir}/X11/twm/system.twmrc\"
+twm_CFLAGS += -DSYSTEM_INIT_FILE=\"$(rcdir)/system.twmrc\"
 
 twm_LDADD = $(TWM_LIBS)
 

We surely don't want this extensive patching, so symlinks (pointing to a direction opposite to the current one) are the preferred solution.

[DJ Lucas]

Yes, they should be moved to /etc/X11/app-defaults and symlinked back as they are the default location, unless we can define rcdir via configure switches. I don't think this is possible, so this should work, also we need to do similar for xterm and Xscreensaver. I think Xsreensaver doesn't like the symlink, but I don't recall for sure. I kind of let it go, also datadir for xterm and Xscreensaver should be reviewed as an aside to this because I found them tonight. Anyway, the commands should be:

mv -v $XORG_PREFIX/lib/X11/{config,fs,lbxproxy,proxymngr,xkb,twm} \
      $XORG_PREFIX/lib/X11/{rstart,xdm,xinit,xsm,app-defaults} \
      $XORG_PREFIX/share/X11/{xedit,Cards,Options,Xcms.txt} \
      /etc/X11 &&
ln -svt $XORG_PREFIX/lib/X11 \
        /etc/X11/{config,fs,lbxproxy,proxymngr,xkb,twm,rstart} \
        /etc/X11/{xdm,xinit,xsm,app-defaults,xedit} \
        /etc/X11/{Cards,Options,Xcms.txt}

[DJ Lucas]

Err..they should be moved to /etc/X11....

[alexander@…]

This is definitely possible, because this bug never existed on the LiveCD. The solution is to pre-create the needed directories and symlinks before installing Xorg. See ​http://wiki.linuxfromscratch.org/livecd/browser/trunk/packages/Xorg-base/Makefile

[alexander@…]

I.e., the LiveCD symlinks only configuration files that are supposed to be changed by the user.

[DJ Lucas]

Okay, I would like the symlink before installation idea, but problem is that we won't know before hand what is going to be installed. If we remove the && in the above instructions, those will work for all cases, but we still wind up with invalid symlinks in $XORG_PREFIX/lib/X11. I'm really happy with the -t example in the ln command because it is rarely used, but I think a loop would be better here I guess. Actually, we _could_ keep it, but it doesn't make much sense since it's only a single symlink...

mv -v $XORG_PREFIX/lib/X11/{config,fs,lbxproxy,proxymngr,xkb,twm} \
      $XORG_PREFIX/lib/X11/{rstart,xdm,xinit,xsm,app-defaults} \
      $XORG_PREFIX/share/X11/{xedit,Cards,Options,Xcms.txt} \
      /etc/X11

for link in /etc/X11/{config,fs,lbxproxy,proxymngr,xkb,twm,rstart,\
xdm,xinit,xsm,app-defaults,xedit,Cards,Options,Xcms.txt}
do
    test -e $link &&
    ln -svt $XORG_PREFIX/lib/X11 $link
done

That's just silly. I'm leaving the link above for example, but the book should use "ln -sv $link $XORG_PREFIX/lib/X11" in the real instructions.

Do the above commands look acceptable?

[alexander@…]

No, because not everything under $XORG_PREFIX/lib/X11 is a configuration file.

config: used by Imake, not supposed to be modified by the end user, don't symlink.

fs: configuration for X font server, symlink.

lbxproxy, proxymngr: please don't build lbx at all, it is not tested anyway and is supposed to be already removed upstream.

twm: real config files, symlink.

rstart: this doesn't look like it is supposed to be user-editable and even contains an ELF binary, Debian doesn't symlink this.

xdm: real config files, symlink.

xinit: real config files, symlink. Also please add an optional security-related step that eliminates one listening port and the need to enable ipv6 in the kernel:

echo -e '#!/bin/sh\nexec /usr/bin/X -nolisten tcp' /etc/X11/xinit/xserverrc && chmod 755 /etc/X11/xinit/xserverrc

xsm: looks like real configuration, it is strange that Debian doesn't symlink this.

app-defaults: symlink.

xedit: symlink (carefully, I am not sure why it showed up in /usr/share/X11)

Cards, Options, Xcms.txt: Debian doesn't even build this since Sarge (oldstable), which is almost three years old, so should we?

As for the "invalid symlinks" problem in the case the user doesn't install everything,

• If they omit components, they are _currently_ on their own, so for 6.3, a big warning about this will be sufficient.

• We can pre-create empty directories to make the symlinks valid even for incomplete installations, anyway.

[alexander@…]

Well, Xcms.txt is simply not packaged, but it looks like an example file anyway, so it is better to symlink it. For reference, these are Debian's Xorg configuration arguments.

confflags += --disable-static \
	     --enable-xorg \
	     --with-mesa-source=/usr/share/mesa-source \
	     --with-default-font-path="/usr/share/fonts/X11/misc,/usr/share/fonts/X11/cyrillic,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" \
	     --with-serverconfig-path=/etc/X11/xserver \
	     --with-rgb-path=/etc/X11/rgb \
	     --enable-xtrap \
	     --disable-dmx \
	     --enable-vfb \
	     --enable-kdrive \
	     --enable-xephyr \
	     --disable-xsdl \
	     --disable-xfake \
	     $(build_xfbdev) \
	     --disable-kdrive-vesa \
	     --disable-lbx \
	     --enable-freetype \
	     --disable-xorgconfig \
	     --disable-xorgcfg \
	     --with-xkb-path=/usr/share/X11/xkb \
	     --with-xkb-output=/var/lib/xkb \
	     --enable-xfree86-utils \
	     --with-os-name="$(shell uname)" \
	     --with-os-vendor="$(VENDOR) ($(SOURCE_NAME) $(SOURCE_VERSION))" \
	     --with-int10=x86emu \
	     --disable-type1

--disable-static: removes useless *.a files, please do the same with all drivers.

--with-\*=/etc/\*: paths

--disable-xorgconfig, --disable-xorgcfg: don't build interactice configuration tools. As demonstrated on the LiveCD, one xorg.conf with a single adjustment (video driver) suits everybody. As a side effect, Cards and Options files (that contain obsolete content anyway) are removed. Anyway, the programs look for these files in $XORG_PREFIX/lib/X11 (see the source), while they are actually installed in $XORG_PREFIX/share/X11. So these programs don't work now anyway, and nobody noticed. Remove them.

--with-int10=x86emu: required for the "vesa" driver and some others that call into the BIOS to work under 64-bit kernels and 32-bit userspace. Yes, I know this is beyond BLFS, but this bug has been reported on the LiveCD and fixed.

--disable-type1: freetype can handle Type1 fonts just fine.

[Randy McMurchy]

After reading all this stuff, I'm not sure anyone is in agreement as to what should be done.

If there are no further comments on this bug, it will either be closed as wontfix or deferred until after the 6.3 release.

[DJ Lucas]

If we take into account all but Alexander's last comment, we can make the needed changes without modifying the existing xorg instructions (except for the symlinks) and have the proper layout. The last of Alexander's comments should be appended to the Xorg-7.3 bug and this bug referenced. I'll get it in a day or two, as I'm kidless all next week. :-)

[DJ Lucas]

For the FHS concern, I believe, from the discussion above, that the best solution is to populate the /etc/X11 directory and create symlinks in $XORG_PREFIX/share/X11, prior to installation. This to be done on the Setting up the Xorg Build Environment page. There is one caveat and that was libdrm or Mesa IIRC, the error was fatal to make. I'm preparing a 6.3 jhALFS run now to test the instructions. The alternative is to add a sed to each package and run automake. Perhaps that can be accomplished by running a sed on the makefile after configure, but I will leave exploration of that route that for Xorg-7.3/7.4.

[DJ Lucas]

Here are the instructions that will go into the book. Now, just need some text to explain it...

install -v -m755 -d \
    /etc/X11/{app-defaults,fs,twm,xdm,xinit,xkb,xsm} &&

install -v -m755 -d $XORG_PREFIX/lib/X11 &&

for link in \
    /etc/X11/{app-defaults,fs,twm,xdm,xinit,xkb,xsm}
do
    ln -sv $link $XORG_PREFIX/lib/X11
done

Cards, Options, and Xcms.txt were left alone, for two reasons. First, they are files and can't be symlinked before they are installed, and second they should probably be left as is because they were there only from the single-tree build and look as if they should be in share/. Following on Alexander's comment above, the $XORG_PREFIX/share/X11/xedit directory contains only lisp routines, it's not likely that they belong in /etc/X11 either. I believe that they should remain in share. Additional comments?

[DJ Lucas]

Additional tickets have been opened for the other two comments above (7 and 8) as #2519 and #2520 with a target of future. When this change is tested and committed, this bug will be closed as the FHS violations, for which this ticket was originally opened, will be taken care of. Additional issues deserve to have their own bug so they do not get lost, or make the current task difficult to read.

[DJ Lucas]

Fixed in r7408.