On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote: > David Nusinow wrote: > > Currently, it fakes FHS compliancy by creating various > > symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate > > directories in /usr/X11R6. For 7.0, we need to make those symlinks become > > actual directories. > > I thought that the idea instead was to move everything directly into > /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories?
/usr/include/X11 is obvious enough (#include <X11/*>). There is some software that contains hardcoded paths to executables in /usr/bin/X11; for example, sshd hardcodes the path to /usr/bin/X11/xauth. sshd stats whatever it thinks is the location of xauth to find out whether it can do X11 forwarding, so it's not entirely trivial to unhardcode this path. > Note that the FHS has this to say about /usr/bin/X11 and friends: > > In general, software must not be installed or managed via the above symbolic > links. They are intended for utilization by users only. I always interpreted this as meaning that packages couldn't install files there via the symlink, but that it was OK to refer to files via the symlink. Current Ubuntu makes /usr/bin/X11 a symlink to . (i.e. /usr/bin) which means that this all continues to work fine after xauth and friends move to /usr/bin. David's paragraph above implies something different. David? > Also, moving stuff to /usr/bin/X11 and making it a real directory will > break things for anyone having /usr/X11R6/bin in their path instead. One > example of such a path is in pbuilder. That much would continue to work fine if binaries were moved to /usr/bin rather than /usr/X11R6/bin, and with a /usr/bin/X11 -> . symlink paths hardcoded as specified in policy (11.8.7, "Installation directory issues") would continue to work as well. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
