Es schrieb "Thomas Bushnell, BSG": > > Harlan Stenn <[EMAIL PROTECTED]> writes: > > > There is more to software than GNU. > > Sure, but the GNU Coding Standards are for GNU, by definition. There > are many things that are disallowed by them in the interests of making > GNU better. For example, info files must all be machine independent. > There is no good reason that GNU man pages should not also be so. > > > If not, think a bit about how your philosophy will unfold, and exactly what > > your goals are. > > I think it is reasonable for the GNU Coding Standards to comply with > the FHS. But the Coding Standards do not need to permit everything > that is permitted by the FHS; they are intentionally narrower.
May be it's because I'm not a native speaker but I would not call it "permit", right? The FHS does to some degree follow established practice and it tries to fold them into a system that we could attribute as being nice to install and maintain. This does not needfully follow the abstract idea of a "prefix" where all other installpaths are just subdirectories/subpaths - (( note the fine macros from adl being built around this: http://ac-archive.SF.net/adl/stdrelpaths.html )) and instead it moves some of the install-dirs out of the prefixed tree, alteast for the /etc and /var data directories. Have a look at my ac macro http://ac-archive.SF.net/guidod/ac_set_default_paths_system.html which should be pretty much readable - e.g. the /opt-prefix makes their configuration files go to /etc/opt and not /opt/etc, and same for many of the localstatedir (i.e. /var) paths which are being moved to hang under a *parallel* prefix in /var - in a way one could condense that for a any prefix /my/prefix the var-files shall go to /var/my/prefix. Personally, I would see atleast two different modes - home-install and system-install. For a home-install, (or local-install) you do usually configure --prefix=$HOME so that the files get installed in (direct!) subdirectories of $HOME - $HOME/bin, $HOME/share and so on, and in fact, many of the FHS intentions (like putting non-modifiables on to a different filesystem) do not count here. In my opinion, this is the original gnu intent for tarball-shipped software since the users do not have the option to install to a system path, and instead I know of many sysadmins who offered a prefix writeable for a group of people, and by some interesting coincidence the group-maintained prefix was often called /usr/local. The other mode is of course a system-install, and in that mode you want to ensure that the /usr-filesys can be mounted readonly, that the basic configurations-files go under /etc and can be saved away in one go, and localstate and pooldir-paths go to the /var-filesys, so as an essence, in system-mode, a prefix like /my/prefix will make the config-files go to /etc/my/prefix instead of /my/prefix/etc which would be correct for a local-install. The macro above does halfwise reflect the modes by looking at the prefix and choosing different defaultpaths for /opt or /usr prefixes but it is certainly in some respects incorrect. But let me say it loud: DO NOT use FHS rules that apply to a /usr-prefix (i.e. a system directory) to talk about rules for a local-prefix (i.e. the gnu default hierarchy). It's two different things and the fact that /usr-binaries use /usr/bin and local-binaries use local/bin should not be made as a general concept for the rest of the install-directories. EPILOGUE: note that most system-install-from-tarball will also see the prefix and configure the gnu software with the different paths like --mandir and the sysconfdir and such - if you have an linux-rpm-system that look into /usr/lib/rpm/macros at the %configure-macro - it usually carries a lot of ac-configure-options for you. note also, that I do not see a specific need to change the mandir path to datadir, but I would put on schedule to be removed completly and make it dependent on a docprefix where info and man-directories can hang form. But I do not see a problem for a non-/share-path for these directories in local-install mode. They can be left there. and note furthermore, that I see one big item that I see as being wrong in current ac/gnu defaultpaths - sharedstatedir should not be put into $prefix/com/ but $sysconfdir/default/, that is it should end up in $prefix/etc/default/. cheers, guido
