Re: [TCLUG:15556] Filesystem structures (was: [TCLUG:15481] Faeriedist)

[Kevin Bullock <kbullock@ringworld.org>]

On Wed, 5 Apr 2000, Dave Sherohman wrote:

> My understanding (based entirely on information that has been sent to this
> list over the last couple days, so it could easily be wrong) is that 'share'
> is supposed to denote platform- and/or architecture-independent files.
> 'local' appears to have been give over to files not derived from the
> distribution's packages.  However, the distribution may include files which
> are platform-/architecture-specific which would, therefore, belong in neither
> (to use the ongoing example of documentation) /usr/local/doc nor
> /usr/share/doc.  Wouldn't these then belong in /usr/doc?  Or is there another
> subdivision that I've forgotten about?

I'm really gonna stop posting to this thread. Really... ;p

AFAIK, *all* documentation is considered architecture-independent. The FHS
doesn't cover OS-independence; this is obviously a bit more complicated; for
example, if you have a Linux+Solaris+Irix heterogenous network, you want the
SGI users to have their ls manpage, the Sun users to have their cp manpage,
and the Linux folks to have their 'cc' work like they expect.

The FHS talks more about a single-OS, multi-arch environment. So all the
architecture-independent stuff, i.e. (again...) manpages, static data that
can be used by multiple platforms, etc. If you have a multi-OS environment,
you would presumably do something like have home directories mounted from
the same place across all OSes, and have on the server a separate NFS export
for each OS (and scale that model up as necessary).

I hope that helps to clear up some of the confusion about these
distinctions.

#ifndef ASBESTOS_H
#define ASBESTOS_H
My intention isn't to harp on this or say that FHS is the One True Way(tm)
of doing things. I'm just trying to help people understand how the FHS works
and the reasons behind its use.
#endif

Pacem in Terris / Mir / Shanti / Salaam / Heiwa
Kevin R. Bullock