autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FHS


From: Guido Draheim
Subject: Re: FHS
Date: Sun, 06 Jan 2002 18:51:59 +0100

Es schrieb "Thomas Bushnell, BSG":
> 
> Harlan Stenn <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]