Subject: Re: HylaFAX woes (hierarchy questions)
To: John Kohl <>
From: Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
List: current-users
Date: 03/12/1995 21:54:22
> This is a narrow distinction that I don't completely grasp yet--whether
> something belongs in /usr/libexec or in /usr/sbin.

do humans invoke it ? /usr/sbin : /usr/libexec


that's pretty much the distinction: if it's meant to _only_ be invoked
by another program, then it goes in libexec.

> Things like the fax queue daemon (faxq) is only normally going to be
> started up once by /etc/rc (which is effectively a program for the
> "executed by another program" metric).  What's the key difference that
> makes it eligible for an sbin directory ?

No, something invoked by rc in "a program executed by a startup
script."  8-)  most rc-ish things go in sbin, becuase it's not
uncommon for one to kill them, and restart them by hand.

stuff like getty, fingerd, inetd, etc., just don't get invoked by hand.

> In another mail message, you quoted the hier(7) man page about what goes
> into /var.  The man page says nothing at all about machine-dependent
> config files, which seem to me to definitely belong to /var (/var being
> a private area per host).  What distinguishes between data that goes
> into /usr/libdata (which is completely empty on my machine, by the way)
> and stuff that goes into /var/... ?

/usr/libdata is for machine-type-dependent (i.e. not dependent on
'hostname', but dependent on the ${MACHINE}) data.

an example is the pascal compiler's strings (though we don't ship the
pascal compiler).  In general, it's considered bad form to have stuff
that should go in libdata.  (another example: if the timezone routines
were poorly written, and the compiled zoneinfo files weren't
machine-independent, they would go in libdata, rather than share.)

> Do config files belong under /var/spool/<something>/etc or should they
> be in /var/<something>/etc (and put true "spool-like things" in
> /var/<something>/spool or /var/spool/<something>)?

as a couple of other people have mentioned, how about /etc/, or

while it would be nice to make /etc/ machine-independent, esp. for
diskless systems, it's not at all clear that this can be done reasonably.