home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / linux / 22592 < prev    next >
Encoding:
Text File  |  1993-01-03  |  4.8 KB  |  121 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!spool.mu.edu!enterpoop.mit.edu!usc!rpi!jfritz
  3. From: jochen fritz <jfritz@rdrc.rpi.edu>
  4. Subject: Re: A discipline for packages
  5. Message-ID: <xc72r-n@rpi.edu>
  6. Sender: jfritz@ptolemy0.rdrc.rpi.edu
  7. Nntp-Posting-Host: ptolemy0.rdrc.rpi.edu
  8. Organization: Rensselaer Polytechnic Institute, Troy, NY
  9. References: <725686556snx@crynwr.com>
  10. Date: Mon, 4 Jan 1993 02:46:08 GMT
  11. Lines: 108
  12.  
  13. In article <725686556snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes:
  14. >You know something I've always hated about Unix (and people are
  15. >starting to hate about Windows)?
  16. >
  17. >When you install a package, it inserts itself inextricably into
  18. >various places in your system.
  19. >
  20. >What I would rather see is a subdirectory per package.  For example,
  21. >/package/sendmail (and the corresponding subdirectories lib, src, cf,
  22. >man.1, man.5, man.8, bin, etc).
  23. >
  24. >This seems a lot cleaner than every program in the world inserting
  25. >itself into /etc, /usr/lib/, /usr/bin, /usr/man,
  26. >/usr/local/lib/package, etc.  Of course, you'd still need to have
  27. >these things inserted into the standard places, so that it still
  28. >looked like a Unix machine.  But this could be done through the use
  29. >of symbolic links and a program that automatically created them.  It
  30. >would walk through /package/*/bin for things to put into /usr/bin,
  31. >/package/*/man* for things to put into /usr/man/man*, /package/*/etc
  32. >for things to put into /etc.
  33. >
  34. >Then, when you wanted to remove a package, you'd just rm -r
  35. >/package/name, then re-run the symlinks builder.
  36. >
  37. >Of course, chasing down all these symlinks is going to make your
  38. >system less efficient.  But that's solvable by creating cache files,
  39. >and gradually improving programs so that they look in the cache files
  40. >instead of at the symlinks.  Of course, the cache files get
  41. >automatically built also.
  42. >
  43. >And, of course, the symlinks builder could also be told to look in
  44. >places other than /package.
  45. >
  46. >Why don't I just go off and do this myself?  Well, because the chief
  47. >benefit comes from easy package installation/removal.  These benefits
  48. >don't come unless people *do* it.
  49. >
  50. >-russ <nelson@crynwr.com> What canst *thou* say?
  51. >Crynwr Software           Crynwr Software sells packet driver support.
  52. >11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
  53. >Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.
  54.  
  55.  
  56. I've been troubled by the same thing.  However, i see the problem as a
  57. little more general.  It seems that root (or bin) should not be the
  58. only one supplying packages, or forcing pachages into people's paths.
  59. Thus, what we need is a system for users to provide and selectivly
  60. install packages.  
  61.  
  62. Here at RPI, they have solved the package management problem.
  63. Hovever, their solution is slow and inelegant.  However, it and the
  64. idea of overmounting did inspire me to plan and prototype a simpler
  65. solution.  In this scheme, all the "usual" little utilities go in /bin
  66. or /usr/bin, however, that's ALL that goes there.  Everything else ius
  67. a package. 
  68.  
  69. Each package is installed in its own directory, and a user makes a
  70. symlink to it to use a package.  Thus a user simply types "setup
  71. /packages/gnuplot".  A few seconds later, they have a set of symlinks
  72. out of their private bin directories to the appropiate binaries.  So
  73. far, my package management scheme consists of the setup program and a
  74. directory layout spec.  A full pathname is given, so a package can be
  75. installed from anywhere in the file system, thus not liniting package
  76. managemant to root.
  77.  
  78. The directory specification is as follows:
  79.  
  80. [package]  - to top level directory
  81.    |
  82.    |--install/ - what needs to be overmounted (bin and man, usually)
  83.    |     |
  84.    |     |----bin
  85.    |     |
  86.    |     |----man
  87.    |     |     |
  88.    |     |     -manX  (eg man1, man2 etc)
  89.    |     |
  90.    |     |----lib  (if this is a library)
  91.    |     |
  92.    |     -----include (if this is a library)
  93.    |
  94.    |
  95.    |--distrib
  96.    |     |
  97.    |     ---src --all source code to the package
  98.    |     |
  99.    |     ---nosrc -- enough stuff (include makefile) to install
  100.    |                 package without full source.
  101.    |
  102.    ---[other stuff] -- runtime support, docs, etc.  Not needed to be
  103.                        accessable by user, but by the package itself.
  104.                        Documentation (beyond man pages) also belongs
  105.                        here.
  106.  
  107. The src and nosrc directory have a Makefile, for which make install
  108. put the binaries and manpage in the install directory.
  109.  
  110. When a package is setup, the install directory is "overmounted" (with
  111. links) on  ~/.setup.  To utilize this, the user must add ~/.setup/man
  112. to MANPATH, and ~/.setup/bin to PATH. 
  113.  
  114. Please give me feedback.  I would post the (simple) setup script, buts
  115. it's at home.  If people request it i'll send it either to them, or
  116. the net.  But what does the c.o.l community feel about this idea.
  117.  
  118. -- 
  119.  
  120. -joe      (jfritz@rdrc.rpi.edu)
  121.