home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0056.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  3.0 KB  |  66 lines
  1. Submitted-by: jmoore@ssd.Kodak.Com (James H. Moore (726-0322)))
  2.  
  3. In article <1991Jul17.195136.29019@uunet.uu.net> brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein) writes:
  4. >
  5. >Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
  6. >
  7. >Under BSD, you can easily set up a /inst/bin directory with symlinks to
  8. >every officially ``installed'' executable. Users can then have /inst/bin
  9. >in their paths instead of all the physical directories like /bin, /etc,
  10. >/usr/bin, /usr/ucb, etc. 
  11.  
  12. This is fine, except when you have to consider shared libraries, and
  13. man page groupings.  Also, what happens when you have multiple releases?
  14. You bring up, and test a new release, but users which are finishing
  15. up a project want a stable, known environment, and insist on keeping the old
  16. familiar version around.  Most likely, you will have to rename some commands,
  17. something.old or something equally tedious and annoying.
  18.  
  19. >Even on System V, you can put hard links in /inst/bin, ...
  20.  
  21. See above:
  22.  
  23. >Anyway, as vendors haven't come to any agreement on this facility---the
  24. >current ``standard'' is to install most programs somewhere under
  25. >/usr/local, with new subdirectories for big programs like ingres
  26.  
  27. We have already found that a single /usr/local, with everything dumped under
  28. there is not optimal, as "local" can have several meanings, e.g. local
  29. to the machine, local to the subnet, common to the division ... .
  30.  
  31. Still, with "big programs" like ingres or say frame maker, what does the
  32. directory structure look like underneath the subdirectory?  It does make
  33. a difference are there multiple architectures? How do you pick up your
  34. architecture?  What if it is a window based tool, and there are different
  35. binaries for different GUIs?  
  36.  
  37. >I despise POSIX's attempts to name any particular solution a ``standard.''
  38. >In the interests of security, efficiency, and backwards compatibility, I
  39. >propose /inst/bin as a viable alternative to getconf. I suggest that
  40. >POSIX look---and take its time looking---before it leaps.
  41.  
  42. We will always be stuck with rearranging directories and renaming them
  43. unless some guidelines are laid down.  Most system administrators that I
  44. know have better, more interesting things to do with their time than
  45. merge man page directories, shared libraries, and rename directories,
  46. and build links.   Sometimes things are so tied to GUI or whatever,
  47. that "common" directories are impossible, and that the encapsulation 
  48. of the vendor needs to be retained.  Can we guide the encapsulation
  49. process and how to recognize particular types of encpsulation?  Can we
  50. talk about what we can mean by "local" ?  How do we handle different
  51. types of locality?
  52.  
  53. >
  54. >---Dan
  55. Thanks for your input
  56.  
  57.                     Jim Moore
  58. -- 
  59. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  60. - - - - James H. Moore, USC, ISPD, Eastman Kodak Co, (716)975-0420  - - -
  61. - -  jmoore@ssd.kodak.com, PROFS: DDTC12(JMOORE)  VMS: DDTC12::JMOORE - -
  62.  May the Lord bless you, in Jesus's name for blessing me with your help!
  63.  
  64. Volume-Number: Volume 24, Number 57
  65.  
  66.