Two development tools we use here expects to find X11 manpages under $PROJECTROOT/man -- the vendor currently has no plans to support linux distributions "which don't follow standards". (note: their words, not mine) Question: would it be possible to make that move optional, perhaps controlled by a local useflag, before unmasking it? Many thanks in advance, and keep up the good work. --
Under FHS, /usr/share/man is standard. /usr/X11R6 and any subdirectories are optional. I suggest you have enhanced the tool to consider this. www.pathname.com/fhs for more info. If you feel the need, create a symlink. That should enable you to continue using the broken tool. Thanks for checking.
I did check FHS 2.2 and 2.3 -- I'm in this business long enough not to risk making an idiot of myself without checking current standards first :)) Here's what LFS says: - /usr/X11R6 : X Window System, Version 11 Release 6 (optional) Purpose This hierarchy is reserved for the X Window System, version 11 release 6, and related files. - An exception [to things layed out in this document elsewhere] is made for the X Window System because of considerable precedent and widely-accepted practice. - Manual pages for commands and data under /usr/local are stored in /usr/local/man. Manual pages for X11R6 are stored in /usr/X11R6/man. # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It follows that all manual page hierarchies in the system must have the same structure as /usr/share/man. - Although it says /usr/X11R6 is optional, what that means is /usr/X11R6 does not need to exist if the system in question does not have the X-Window System installed. A symlink as suggested in comment #1 won't help because system and X11 manuals are expected in different trees (it's not broken). I guess this bug should be a WONTFIX then, because it certainly is not INVALID :) --
"Although it says /usr/X11R6 is optional, what that means is /usr/X11R6 does not need to exist if the system in question does not have the X-Window System installed." Any reference for this, or is it a personal interpretation? I am not alone in considering the /usr/X11R6 hierarchy broken behavior (so does FHS, calling it an exception) and intend to get rid of it entirely. This bug should really be filed with the proprietary tool vendor, since I consider nothing to be wrong with our distribution of X11 in this respect.
Please ignore my ignorance, but which one of the other "big players" considers X11 in its own tree "broken behaviour"? Why do you? Maybe time will tell differently but right now /usr/X11R6 is an established standard and all I'm asking is to make a different layout optional because everything else is unsupported by some vendors, at least at this time.
would a symlink /usr/X11R6/man -> /usr/share/man not work for you?
Mike Harris of Red Hat, Keith Packard of freedesktop.org and Daniel Stone of freedesktop.org and Debian among others agree that X should live in the "real" filesystem like everything else.
No, as said in comment #2, system and X11 manpages are expected to be in separate trees. I just read the comments in the xfree ebuild that indicate you're going to abandon /usr/X11R6 entirely. If the opinion of one single person counts, my opinion is I have a very bad feeling about abendoning standards too fast. In addition to what's already said above, our policy here for example is to have X11 binaries in PATH for local logins only. Which does not prevent people from adding /usr/bin/X11 (/usr/X11R6/bin in Gentoo) to their path, it's just not there by default (just as *sbin is not in the default PATH for regular users, even though some programs in there are still useful for them, and you don't want to question the existence of sbin, do you?) IMHO the most consistent Linux in this respect is still SuSE who have all X11-only binaries in /usr/bin/X11. But that is really OT here. With respect to manpages (what this bug is all about), see for example also bug #29541: you'll have /usr/share/man/man4/mouse.4 and /usr/share/man/man4/mouse.4x. Debian's man-db would be able to distinguish between the two by subsection, but standard man does not. Xman allows to divert different man trees to their own virtual section by clever use of mandesc files, but not if /usr/X11R6/man is a symlink to /usr/share/man. FHS (sorry I said FHS above) also still says "Manual pages for X11R6 are stored in /usr/X11R6/man". Don't get me wrong, I'm all for new things, but I still think until officially supported distributions switch to the new layout there should be an option to stick with the old layout until the time is right.
If you wish to change your local ebuild, it's as simple as changing this line in the ebuild: echo "#define ManDirectoryRoot /usr/share/man" >> config/cf/host.def If it will help, we're willing to add the symlink. Will it? Regarding the issue of man pages with the same name in the same section, if it happens it's a bug and should be treated as such.
I'm a bit confused -- are we still talking about the same here? FHS clearly says X11 manual pages belong in /usr/X11R6/man -- You say they are moved to comply with FHS but it's actually in violation of FHS. I repeatedly say a symlink does not help. -- You keep asking if a symlink would help. Getting rid of /usr/X11R6 clearly breaks some closed source apps -- You say the current behavior is broken. The last point is not because the actual exact location really matters -- the key here is if the same binary is supposed to run on different linux distributions, certain X11 files need to be in the exact same location on all supported distributions. Another reason /usr is a bad choice is it makes it impossible to install different compatible X11 implementations simultaneously -- with one implementation installed in /usr you'd end up with multiple libs with the same soname in ld.so's search path -- messy at least, but not even an option on Gentoo due to a bug/feature in all newer ldconfig's /lib and /usr/lib are always searched before directories in ld.so.conf instead of last which makes overriding libs in /usr/lib impossible. (corrected in SuSE-9 and Fedora, never been a problem on Debian) --
> FHS clearly says X11 manual pages belong in /usr/X11R6/man > -- You say they are moved to comply with FHS but it's actually in violation of > FHS. FHS says /usr/X11R6 is an exception. We're eliminating that exception. It in no way says /usr/X11R6 is required. > I repeatedly say a symlink does not help. > -- You keep asking if a symlink would help. Yes, because that's what I'm willing to offer. > Getting rid of /usr/X11R6 clearly breaks some closed source apps > -- You say the current behavior is broken. True. It should consider all possible man page locations as considered in the `man man` page (SEARCH PATH FOR MANUAL PAGES). > The last point is not because the actual exact location really matters -- the > key here is if the same binary is supposed to run on different linux > distributions, certain X11 files need to be in the exact same location on all > supported distributions. Such as? A symlink should solve this problem in the bin/ and lib/ cases. Also, since to my knowledge most distributions install /usr/X11R6/lib/X11/config/, all locations should be potentially readable from there. > Another reason /usr is a bad choice is it makes it impossible to install > different compatible X11 implementations simultaneously That's the packager's job to deal with. > -- with one implementation installed in /usr you'd end up with multiple libs > with the same soname in ld.so's search path -- messy at least, but not even an > option on Gentoo due to a bug/feature in all newer ldconfig's /lib and > /usr/lib are always searched before directories in ld.so.conf instead of last > which makes overriding libs in /usr/lib impossible. (corrected in SuSE-9 and > Fedora, never been a problem on Debian) Please file a separate bug for this. I'll refer you to http://freedesktop.org/pipermail/x-packagers/2004-February/000005.html for one viewpoint of many of these issues also.
No, no, no, applications don't read lib/X11/config, in most distributions this directory exists only if the x11-devel package is installed, it is in fact the _source_ of _compiled in_ paths in Imakefile based sources. That's not a bad thing, seeing that the same sources compile on many flavours of UNIX, X11 could be in /usr/openwin, /usr/dt, /opt/dt, /usr/X11R6 -- on SUNs there even could be SUN and MIT X11 trees at the same time -- but they all have one thing in common: if imake is set up properly the same config variable always points to the same location on all binary compatible OSs. As said, the absolute value is not important (except that /usr is suboptimal for various reasons), what really matters is that all distributors follow the same standard at the same time. If RedHat and Debian support a different location I'm sure it will make it into the next FHS, but in current FHS it's /usr/X11R6 and that's what third party software supports.
