Wow, I completely missed most of the discussion. I would just like to state that the FHS does call for /usr/local, used in the BSD distros. As was already stated, it was supposed to be a coming together of all the mess going on, but it failed. It's still, by default, used by most packages I know of. Binaries go in /usr/local/bin, conf files in /usr/local/etc, etc... The FHS does require /usr/local for "locally" installed software ( http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY). But it don't require /etc/ld.so.conf to even be present ( http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS5), so the argument about ld.so.conf is moot. If I understand the FHS correctly, it is the sys admin's job to add a ld.so.conf if he/she is installing software in /usr/local. What makes the other Unix variants not compliant with the FHS is all the /usr/share stuff. Some install man pages in /usr/share/man, other in /usr/man, etc. Slackware, for example, symlinks /usr/share/man to /usr/man. There's also the /media and /mnt argument. In any case, the FHS is probably the most correct option for all Unix-like environments. Like it or not, the BSDs already comply with the important parts of FHS, and those are the parts GNUstep uses.
As was already linked a few times, the GNU coding standards require adherence with a few installation dir variables. Shouldn't GNUstep have something like that? If I remember correctly, most GNU package have --with-libexecdir=, --with-prefix=, etc options in configure. Sorry if I don't make a lot of sense, I just wanted to throw everything going through my head down.
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
