robert@pvab.UUCP (08/28/87)
I know that this question has been asked before, but I can't find
that article.
I'm a little curious about how I should organize our local
directories. Where should I put sources, binaries, libes, and so on.
I've been recommended by various people to put my binaries in
/usr/local, /usr/local/bin, /usr/lbin, and even /usr/bin (which AT&T
recommends in their SVID, I think). About the same applies for
sources. /usr/src/local, /usr/local/src, and /usr/lsrc are the names
I've seen. Applications (such as Uniplex, Informix, Today) can be
placed under /usr, /usr/appl, /usr/lib, /usr/opt, /usr/local, among other
places. User's home directories under /usr, /usr/u and /usr/users.
The directory jungle is BIG, and it is getting bigger. We have a network
of several machines from different vendors, of which most of them
runs NFS (including PC's).
--
SNAIL: Robert Claeson, PVAB, P.O. Box 4040, S-171 04 Solna, Sweden
UUCP: {seismo,mcvax,munnari}!enea!pvab!robert
ARPA: enea!pvab!robert@seismo.arpagwyn@brl-smoke.UUCP (09/01/87)
In article <311@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: >I'm a little curious about how I should organize our local >directories. Where should I put sources, binaries, libes, and so on. >I've been recommended by various people to put my binaries in >/usr/local, /usr/local/bin, /usr/lbin, and even /usr/bin (which AT&T >recommends in their SVID, I think). /usr/bin is simply wrong, but otherwise your system should already have such a directory you can use. It makes little difference what name you use. Many add-on application packages (e.g. a DBMS or the 5620 DMD software) really want their own separate directories. The main other consideration is disk space. If you have symbolic links, you have much more freedom to place directories where there's room. >About the same applies for sources. /usr/src/local, /usr/local/src, >and /usr/lsrc are the names I've seen. You should use the name closest to the one for your binaries. Be sure not to put local stuff unnecessarily in system directories. Sites that have done that have eventually learned why it's a bad idea, but I'll give you a clue: How easy is it to upgrade the system?
barnett@vdsvax.UUCP (09/01/87)
In article <311@pvab.UUCP> robert@pvab.UUCP (Robert Claeson) writes: | |I'm a little curious about how I should organize our local |directories. Where should I put sources, binaries, libes, and so on. The method that works best for me is (assuming a large group of Suns & etc. ) is to create a directory /usr/$server/local, and create a symbolic link ln -s /usr/$server/local /usr/local I then create various directories (i.e. bin, etc, doc, src, man, include, lib, new, msgs ) inside this directory. I then create links that point to these directories. e.g. ln -s /usr/local/lib /usr/lib/local ln -s /usr/local/msgs /usr/msgs ln -s /usr/local/man /usr/man/manl ln -s /usr/local/etc /etc/local ln -s /usr/local/include /usr/include/local ln -s /usr/local/new /usr/new ln -s /usr/local/src /usr/src/local etc. In other words - all of the local stuff is in /usr/$server/local. All of the other directories point to the proper /usr/local subdirectory. This has several advantages: 1. Local additions are easier to retain on system updates. 2. All services provided by a file server that need files tend to have all of the files available, once the links are set up. This is especially true when you make the /usr/$server/local directory exported, but not /usr 3. Because /usr/local points to /usr/$server/local, you can change pointer to a new server when one server goes down. I usually make /usr/$server/local group `staff', so the support staff can add updates to the local directories ( with the exception of /usr/local/etc perhaps) Perhaps there should be several /usr/local/bin directories, once for each machine type, so you can include in the searchpath set path = ( $path /usr/local/`arch`bin /usr/local/bin) where the scripts go into /usr/local/bin, and the machine dependant binaries go into /usr/local/<machine>/bin. Any comments? -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
allbery@ncoast.UUCP (09/02/87)
As quoted from <311@pvab.UUCP> by robert@pvab.UUCP (Robert Claeson): +--------------- | I'm a little curious about how I should organize our local | directories. Where should I put sources, binaries, libes, and so on. | I've been recommended by various people to put my binaries in | /usr/local, /usr/local/bin, /usr/lbin, and even /usr/bin (which AT&T | recommends in their SVID, I think). About the same applies for | sources. /usr/src/local, /usr/local/src, and /usr/lsrc are the names | I've seen. Applications (such as Uniplex, Informix, Today) can be | placed under /usr, /usr/appl, /usr/lib, /usr/opt, /usr/local, among other | places. User's home directories under /usr, /usr/u and /usr/users. +--------------- The directory structure I usually use is: /bin - Single/multiuser UNIX standard commands /lib - Singleuser UNIX standard libraries/control files /etc - Singleuser UNIX system maintenance files/commands /usr - "UNIX service routines" bin -- Multiuser UNIX standard commands lib -- Multiuser UNIX standard libraries/control files etc -- Multiuser UNIX standard maintenance files/commands local -- Locally added files bin -- Locally added commands lib -- Locally added libraries/control files etc -- Locally added system maintenance files/commands /u - User home directories (sometimes /user instead) /appl - Applications, by application (examples below from TDI) mcs (Manufacturing Control System) unify (UNIFY 3.2) isql (Informix-SQL) coesys (COE system written in UNIFY) /proj - Locally developed applications sources (again, examples from TDI) fc (Forecasting programs for COE system) ml (Mailing list database) gl (General Ledger programs for COE system) routing (Route sheet database) unify (Locally developed UNIFY tools) This makes it easy to figure out where things are: system tools and commands are kept in directories with the same structure, and applications are stored by their commonly-known names. -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> ** Site "cwruecmp" has changed its name to "mandrill". Please re-address ** *** all mail to ncoast to pass through "mandrill" instead of "cwruecmp". ***