On the subject of extraction out of the
Xorg-7.4 extension components that are usable by other X servers (e.g. the default 'Xvesa') I was wondering whether this could be applied to some executables included in that extension. I had to install on occasion this rather "weighty" extension (ca. 25 MBytes incl. dependencies) just to get hold of a single executable (e.g.
xev).
I therefore thought to impose two conditions onto such an "exercise":
- The executable should not depend on a shared library not available in a "base" TC system. In particular not a shared library included in 'Xorg-7.4.tcz'.
- Another version of the executable should not be included in the "base" TC system.
On that basis I made an attempt to "extract" a 'Xorg-tools.tcz' extension out of 'Xorg-7.4.tcz' via running through the following "steps" (using a "base" TC system):
XORG=Xorg-7.4
EXTR_DIR=${XORG}_extr
PKG=Xorg-tools
PKG_DIR=${PKG}_pkg
tce-fetch.sh ${XORG}.tcz 2> /dev/null
which mksquashfs > /dev/null || tce-load -wi squashfs-tools-4.0 2> /dev/null
sudo unsquashfs ${XORG}.tcz > /dev/null
sudo mv squashfs-root $EXTR_DIR
find $EXTR_DIR -name bin | while read DIR ; do
ls $DIR | while read NAME ; do
FILE=${DIR}/${NAME}
LIBS=$( ldd $FILE 2>&1 )
ERR=$( echo "$LIBS" | grep 'error' )
RES=$( echo "$LIBS" | grep 'not found' )
if [ -z "${ERR}${RES}" -a -z "$( which $NAME )" ] ; then
TARGET_DIR=$( dirname $FILE | sed "s#^${EXTR_DIR}/##" )
TARGET_DIR="${PKG_DIR}/${TARGET_DIR}"
[ -d $TARGET_DIR ] || sudo mkdir -p $TARGET_DIR
sudo mv $FILE ${TARGET_DIR}
fi
done
done
mksquashfs $PKG_DIR ${PKG}.tcz > /dev/null
mv ${XORG}.tcz ${XORG}-original.tcz
mksquashfs $EXTR_DIR ${XORG}.tcz > /dev/null
sudo rm -rf $EXTR_DIR $PKG_DIRI'm now wondering if this might be considered as a possible change for the TC 3.x (or even also the 2.x) repository. Obviously this would require for 'Xorg-tools.tcz' to be added to 'Xorg-7.4.tcz.dep'.
Please note I have not done a huge amount of testing, and it is quite likely that there will be executables that don't work with another X server. OTOH I don't see to much risk in that approach and I also can't see much of a downside from a 'Xorg' point of view.
Edit: To make it more obvious what would be in 'Xorg-tools.tcz' here is the list:
tc@box:~$ find /tmp/tcloop/Xorg-tools/ -name bin | xargs ls -l
/tmp/tcloop/Xorg-tools/usr/bin:
total 40
-rwxr-xr-x 1 root root 16512 Apr 25 2009 cxpm
-rwxr-xr-x 1 root root 10048 Apr 25 2009 makestrs
-rwxr-xr-x 1 root root 12996 Apr 25 2009 sxpm
/tmp/tcloop/Xorg-tools/usr/local/bin:
total 467
-rwxr-xr-x 1 root root 5100 Apr 25 2009 appres
-rwxr-xr-x 1 root root 6480 Apr 25 2009 atobm
-rwxr-xr-x 1 root root 4900 Apr 25 2009 bdftopcf
-rwxr-xr-x 1 root root 61436 Apr 25 2009 bitmap
-rwxr-xr-x 1 root root 5016 Apr 25 2009 bmtoa
-rwxr-xr-x 1 root root 8120 Apr 25 2009 cvt
-rwxr-xr-x 1 root root 7500 Apr 25 2009 gtf
-rwxr-xr-x 1 root root 18216 Apr 25 2009 iceauth
-rwxr-xr-x 1 root root 28088 Apr 25 2009 luit
-rwxr-xr-x 1 root root 19120 Apr 25 2009 makedepend
-rwxr-xr-x 1 root root 21156 Apr 25 2009 mkfontscale
-rwxr-xr-x 1 root root 6088 Apr 25 2009 sessreg
-rwxr-xr-x 1 root root 13364 Apr 25 2009 smproxy
-rwxr-xr-x 1 root root 12492 Apr 25 2009 ucs2any
-rwxr-xr-x 1 root root 6364 Apr 25 2009 xbacklight
-rwxr-xr-x 1 root root 19680 Apr 25 2009 xcmsdb
-rwxr-xr-x 1 root root 15448 Apr 25 2009 xev
-rwxr-xr-x 1 root root 10000 Apr 25 2009 xhost
-rwxr-xr-x 1 root root 11656 Apr 25 2009 xinput
-rwxr-xr-x 1 root root 14616 Apr 25 2009 xkbvleds
-rwxr-xr-x 1 root root 11316 Apr 25 2009 xkbwatch
-rwxr-xr-x 1 root root 5312 Apr 25 2009 xlsatoms
-rwxr-xr-x 1 root root 6096 Apr 25 2009 xlsclients
-rwxr-xr-x 1 root root 23528 Apr 25 2009 xprop
-rwxr-xr-x 1 root root 35240 Apr 25 2009 xrandr
-rwxr-xr-x 1 root root 18292 Apr 25 2009 xrdb
-rwxr-xr-x 1 root root 6596 Apr 25 2009 xrefresh
-rwxr-xr-x 1 root root 4592 Apr 25 2009 xsetmode
-rwxr-xr-x 1 root root 10072 Apr 25 2009 xsetroot
-rwxr-xr-x 1 root root 17292 Apr 25 2009 xwd
-rwxr-xr-x 1 root root 20244 Apr 25 2009 xwininfo
-rwxr-xr-x 1 root root 18804 Apr 25 2009 xwud