home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0046.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  4.7 KB  |  102 lines
  1. Submitted-by: jmoore@ssd.Kodak.Com (James H. Moore)
  2.  
  3. I just tried to post a question to comp.doc and 
  4. comp.unix.question regarding this very subject.  Although
  5. no longer in system administration, I now answer questions
  6. for users, and recently tried to create a .login file that
  7. would pick up appropriate paths of executables, shared
  8. libraries, and on-line manual pages.  I ran into some
  9. file system structure roadblocks, and asked a similar question
  10. regarding standards, do they exist and what can be done.
  11.  
  12. Specifically, I found in trying to create a .login file
  13. that would localize variances of networks within our 
  14. division, while allowing for variability in architecture,
  15. operating system level, GUI as well.  (Sooner or later
  16. you may have to deal with natural language variables as
  17. well.   For europe, it is probably sooner -- like now).
  18. I dealt with various philosophies, and problems.
  19.  
  20. The most visible was how many levels of sharing are permitted,
  21. and how vendors package software.  I know that many vendors 
  22. put packages under /usr for convenience.  Most system 
  23. administrators move these elsewhere to a partition(s) which
  24. won't be wiped out at the next system upgrade.  [This is a
  25. standard enough practice, from my limited visibility.  If
  26. someone would standardize on a name for this applications 
  27. partition - local candidates include /licensed, /licensed4,
  28. /packages or any one of the previous under the /u directory]
  29.  
  30. How authors/vendors view their "space" seems to differ.  
  31. Frequently there is "encapsulation", where a vendor puts
  32. everything binaries, configuration files, shared libraries,
  33. and manual pages under one heading, the package name.  That
  34. is fine, it make individual package upgrades easy. If the 
  35. application uses an environment variable, and a shell script 
  36. which add appropriate things to access shared libraries, and
  37. man pages, you are in good shape, you can even run multiple 
  38. versions at once (like testing a new version when it comes 
  39. out, or allowing projects near completion to finish without
  40. using the new an improved version).
  41.  
  42. But often there are naming problems in subdirectories: sometimes
  43. the encapsulation is by architecture, so you have .../vendor/bin
  44. .../vendor/lib etc.  These are picked off of the distribution
  45. tape by architecture.  
  46.  
  47. Others, create the main directory, and then pick off 
  48. architectures one by one, allowing the sharing of man 
  49. pages and configuration or data files.  
  50.  
  51. E.g. .../vendor/sun3/bin .../vendor/sun3/lib .../vendor/sun4/bin 
  52. .../vendor/sun4/lib .../vendor/share .../vendor/etc  [sometimes
  53. the "etc" directory is under "share", othertimes it is not.
  54.  
  55. Some do like "." better than "/". So you find .../vendor/bin.sun3
  56. and .../vendor/bin.sun4.  This saves no keystrokes, and usually
  57. implies that the applications do not make use of shared libraries.
  58.  
  59. When the applications make use of a GUI, things get more 
  60. interesting.  Most append an X somewhere for X applications.
  61. Others do things with "ow" for OpenWindows(tm) (actually OpenLook
  62. (tm)), and "m" for Motif(tm).  The problem is that these
  63. postfixes can be anywhere, and sometimes users have a menu
  64. to select a windowing system in their .login.
  65.  
  66. After the "encapsulated" approach is the "installed" approach,
  67. where binaries are added to /usr/bin, man pages to /usr/man, libraries to /usr/lib, and data to /usr/etc.  This works, 
  68. leveraging existing mechanisms to provide the user with access.
  69.  
  70. Two last issues surface, in a related way, from a users perspective,
  71. in getting access to the applications that they want.
  72.  
  73. One is a concept of "locality" - i.e. what is "local".  What
  74. needs to be local to the machine, working group, subnet, and
  75. what is "global" to the organization.  This has a lot of
  76. facets, mainly centered around how you handle overlap.
  77.  
  78. The second concept has to do with a concept that I have seen
  79. prototyped in yellow pages, and bantered around as being part
  80. of the file system.  Create tables for users, either tables
  81. of paths for users (distributed via rpc program or yellow
  82. pages), or have a part of the directories files which define
  83. variability, and set up user's paths and variables for them
  84. ("source" files, or environment scripts).
  85.  
  86. The issue of standardizing encapsulation seems to be the easiest,
  87. and would probably make system managers and users lives a lot
  88. simpler.
  89.  
  90. Has anyone worked these things out?  Are there RFCs?  Is
  91. POSIX.7 addressing these?
  92.  
  93. Thanks for listening.  Thanks for any help or suggestions.
  94.  
  95. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  96. - - - James H. Moore, USC, ISPD, Eastman Kodak Co, (716)726-0322  - - -
  97. -  jmoore@ssd.kodak.com, PROFS: DDTC12(JMOORE)  VMS: DDTC12::JMOORE - -
  98. May the Lord bless you, in Jesus's name for blessing me with your help!
  99.  
  100. Volume-Number: Volume 24, Number 47
  101.  
  102.