home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / linux / 25248 < prev    next >
Encoding:
Text File  |  1993-01-24  |  2.6 KB  |  65 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!bcstec!aw108!vds7789
  3. From: vds7789@aw2.fsl.ca.boeing.com (Vincent D. Skahan)
  4. Subject: Re: SLS: how do we know we've caught up ?
  5. Message-ID: <1993Jan23.194223.2750@aw2.fsl.ca.boeing.com>
  6. Organization: none
  7. References: <1993Jan20.235409.201@victrola.sea.wa.us> <1993Jan22.035103.21040@sol.UVic.CA>
  8. Date: Sat, 23 Jan 1993 19:42:23 GMT
  9. Lines: 54
  10.  
  11. pmacdona@sanjuan (Peter MacDonald) writes:
  12.  
  13. >Actually, currently there really isn't a "version" of SLS.  Instead, each
  14. >package can be updated without notice.
  15.  
  16. I know...I meant 'version of each kit' but if you do something like make
  17. v1.0000 mean the whole virgin distribution and make the next update of
  18. a kit (whatever it is) v1.001, the one after that v1.002, etc. it'll wind
  19. up being the same.
  20.  
  21. >What was just added to SLS is that, everytime you install a disk, it
  22. >updates a file in /install/disks/diskXN with the package name, and
  23. >the size in bytes of the package.  Thus you can always tell if the
  24. >package you installed is the same size as some other one.  And thus,
  25. >with 99.9% certainty, you should be able to tell if you have the
  26. >same package.
  27.  
  28. not for a1 and a2. They're always the same size.
  29.  
  30.  
  31. >Now this by itself is of marginal value, but I plan on implementing a
  32. >(bash) script that will drive an automatic updating scheme based upon
  33. >this information.  Thus the "version" of SLS will be the sum of all
  34. >these sizes.  ie, it can determine the current version, and update
  35. >accordingly.
  36.  
  37. you can't sum all the sizes because we don't all install all of SLS.
  38. So my 'sum-of-the-sizes' is different from everybody else's.
  39.  
  40. >This scheme is not bullet proof, but exacts nearly zero overhead, and
  41. >in practice should be quite reliable.  And, most important of all, doesn't
  42. >exact any extra administrative overhead.  It also has the advantage that
  43. >you can always find which disk a package is on by doing:
  44. >    fgrep pkg.tpz /install/disks/disk*
  45.  
  46. can you really?
  47. won't it just tell you where *your installed copy* of it came from ?
  48.  
  49. but in general, what you're coming up with is along the lines of what
  50. I was asking for.  I want something to:
  51.  
  52.     - positively know what version of what kit(s) I've installed
  53.     - positively know what the CURRENT version of all kits is
  54.     - positively know what disk the CURRENT version of everything
  55.         is supposed on
  56.  
  57.     - and most importantly, do it for ZERO work for me (as a user)
  58.         and hopefully close to zero work for you too :-)
  59.  
  60.  
  61. -- 
  62.    ---------   Vince Skahan   ----- vds7789@aw101.iasl.ca.boeing.com ------- 
  63.    I make it a point to always have something from each of the five basic 
  64.    food groups....salt, sugar, fat, grease, and alcohol.
  65.