home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / linux / 22322 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  3.1 KB
  1. Path: sparky!uunet!utcsri!turing.toronto.edu!ruhtra
  2. Newsgroups: comp.os.linux
  3. From: ruhtra@turing.toronto.edu (Arthur Tateishi)
  4. Subject: Re: A discipline for packages
  5. Message-ID: <1992Dec31.190701.26910@jarvis.csri.toronto.edu>
  6. Organization: CSRI, University of Toronto
  7. References: <marcf.725692346@yorku.ca> <T8BmwB1w165w@kf8nh.wariat.org> <1992Dec31.022954.5807@sol.UVic.CA>
  8. Date: 1 Jan 93 00:07:01 GMT
  9. Lines: 52
  10.  
  11. In article <1992Dec31.022954.5807@sol.UVic.CA> pmacdona@sanjuan (Peter MacDonald) writes:
  12. >In article <T8BmwB1w165w@kf8nh.wariat.org> kf8nh@kf8nh.wariat.org (Brandon S. Allbery) writes:
  13. >>marcf@nexus.yorku.ca (Marc G Fournier) writes:
  14. >>> nelson@crynwr.com (Russell Nelson) writes:
  15. >>> >You know something I've always hated about Unix (and people are
  16. >...
  17. >>If, in my copious spare time [ ;-) ] I can manage to put together an
  18. >>install/uninstall/update package that works that way, I'll be glad to donate
  19. >>it to Peter so SLS will have a better install/uninstall package than the
  20. >
  21. >Actually I responded via email to Neslon's initial suggestion.  The 
  22. >gist of it is there is no benefit to the symbolic links idea.
  23. >SLS already allows easy uninstall (not that anyone uses it)
  24. >via "sysinstall -remove pkg".
  25.  I DID! I DID! (I nuked emacs before even continuing with the x? disks :-)
  26.          <Remember, this isn't comp.editors. I just didn't want it
  27.          taking up space on my disk.> )
  28.  
  29. >Symbolic links turn out to be a system admins nightmare, and I am thinking
  30. >seriously about clensing SLS of all such, except for directories.
  31. >While hardware is cheap, slowing it down makes no sense.
  32.  I Agree
  33.  
  34. At first glance, I thought SLS _WAS_ just untarring a bunch of files,
  35. etc.  But on closer inspection, each package has mechanisms for
  36. installation, removal, AND EXTRACTION, not to mention things like
  37. having scripts be able to compress/uncompress man pages and fonts
  38. after/before installation/extraction.  If you simply keep a list of
  39. personally installed packages and use sysinstall -extract <package> and
  40. stash these away before upgrading all would be fine.
  41.  
  42. The other thing I really like about the sysinstall way of doing things
  43. is being able to go into a directory, see what packages I've got, and
  44. be able to quickly see where things got installed.
  45.  
  46. The original poster wanted something to manage wholesale upgrades of
  47. SLS.  Simply having a simple way to install and remove packages doesn't
  48. cut it.  If you follow the SLS package paradigm when installing local
  49. things, you can easily extract them to a separate fs before upgrading
  50. and re-install afterwards. If they install by typing "make install" you
  51. should either setup your own directories and symlinks or make a quick
  52. SLS package install/remove/extract script.
  53.  
  54. Peter, keep up the good work. As the fellow who dealt with 386BSD before
  55. SLS Linux said, "386BSD could really use this technology."
  56.  
  57. arthur
  58. -- 
  59. "The first fact to face is that UNIX was not developed with security, in any
  60. reliable sense, in mind; this fact alone guarantees a vast number of holes."
  61.     -- "On the Security of UNIX", Dennis M. Ritchie
  62. Arthur Tateishi                 ruhtra@turing.utoronto.ca
  63.