jn@bbn.com (John Robinson) (07/07/89)
In article <PINKAS.89May16141851@hobbit.intel.com>, pinkas@hobbit (Israel Pinkas ~) writes: >Our configuration is a "dataless workstation model". Swap space (anywhere >from 16M to 100M) is local. The kernel, and most of the "basic" binaries >distributed are local. User directories, /usr/local, etc. are NFS mounted. >We run primarily on Suns and uVaxen. > >With this configuration in mind, my orginal statement(s) makes more sense. Indeed. Wish we had so many disks... >What we have done is implement a methodology. Instead of removing the >file, rename it. (i.e. emacs -> .emacs.orig) The delete it a week later. The method we have adopted here for emacs may be of interest to the net. For most users, issuing the command `emacs' at a shell invokes /usr/local/bin/emacs. This file is a symbolic link to /usr/local/emacs/dist/xemacs. In /usr/local/emacs, dist itself is a symbolic link to, for example, dist-18.53. /usr/local/emacs/src, in turn, is a sym link to dist/src, and ditto for man, info, lisp, etc, etc. In a NFS environment, we put the less-used subdirectories (src, man, info, cpp) on a subset of the file servers, with links from the other servers at the dist-XX.XX level to preserve version consistency. (This may fool you if you are navigating within the subdirectories with cd ../foo). lisp and etc we copy to each file server. In dist-18.53/, xemacs is a hard link to src/emacs-18.53.X, where X is the current minor version number. [For the less fortunate file servers, we cp -p the new executables from the server with all of src/; this could lead to stale file handles unless you mv the older minor version out of the way]. I find this scheme pretty workable, for the following reasons: 1. The dist-XX.XX naming is consistent with emacs as distributed, especially diff files. Makes patching easier. 2. A major release is accomplished simply by changing the dist symlink in /usr/local/emacs to the right new major version number. Although this makes the lisp files inconsistent with the executable, we haven't found this to be a major problem. 3. A minor release is accomplished by unlinking dist-XX.XX/xemacs and relinking it to (the newer) src/xemacs. Since the old version stays around in src/ with its explicit version name (emacs-XX.XX.X), we avoid stale file handles. 4. Once a version is superseded, we wait a week or more before removing the executable (or distribution) altogether. 5. Note that DOC files often are the same between minor version numbers. You can save space by hard-linking them together. Also, we have to hard-link DOC files between the etc/ directories of the various dist-XX.XX trees to smooth major version transitions. (Generally, there will only be at most two major version active at a time.) We don't try to extend this across architectures (yet). We are sort of toying with that problem for TeX... Note: I don't read comp.unix (whither followups), so please cc me on any interesting replies...thanks. -- /jr jr@bbn.com or bbn!jr C'mon big money!