Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!deimos!mccall!tp From: tp@mccall.uucp Newsgroups: news.software.anu-news Subject: Re: patching Message-ID: <1989.25b5fc11@mccall.uucp> Date: 18 Jan 90 17:25:36 GMT References: Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 98 In article , JOHNSON@NORTHEASTERN.EDU (I am only an egg.) writes: > The simpler the betterer. I think one of my bigger objections is > that most patching requires human intervention in some way or other. I beg to differ. I just got the VMS port of Larry Wall's patch utility (out of vmsnet.sources). I've been a fan of this utility for a long time, as I used to work on unix systems. It has always worked just about flawlessly. The VMS version seems just as solid (with the recently posted patch by Karsten Nyblad). I really gave it a work out. I didn't have the 5.9 sources, just 5.9a and 5.9b, which I produced by laboriously applying the 5.9b diffs to 5.9a and ignoring the parts that were already done. Since I still had the 5.9b diffs, I ran them against the 5.9b sources and let it reverse all the patches. Now I have a 5.9 baseline source to apply updates to. Then I ran the 5.9c diffs. Everything worked without a hitch! Suggestion: if you copy all the patches into one file, you can do the whole patch operation with one command, and you are sure of not missing any. > People are prone to screw-ups, some of us more than others. Plus the > fact that sometimes various networks chuck in their two cents worth. I > still remember a set of patches from a v5.8 that got folded to 80 > characters and messed up the patching that way. Patches distributed as VMS_SHARE's are supposed to be immune to all but the worst network munging. Nothing is perfect however. I assume you are on the mailing list rather than the newsgroup. I'm surprised if the munged patches actually checksummed ok, though. > I'll take any suggestions to make life simpler and safer for > everyone. If a couple of typed command lines would update me from a > base version them I'm all for it. OK, a couple of suggestions. The distribution of rn and b news software on unix seems to work quite well. There are a few things they do that I think work better than the way we are doing ANU NEWS. 1) Define a file to hold the patch level. For instance, create a file newsversion.h and have it contain only the news version, including patch level. This can then be checked by the Prereq: feature of patch to ensure that the patch is being applied to the appropriate version and patch level of the source (this file would always be patched first, so if there is a problem, you can stop before making any changes. (This version should be what is reported by the VERSION control message, and all other places the version is displayed.) 2) Distribute each patch relative to the previous patch, rather than a base level. This would allow one to receive already patched sources rather than having to get a base level and apply patches (for people just getting the software). Also, you wouldn't have to keep 2 copies of it around (base level and current level). 3) Have someone (in this case, obviously Geoff) in charge of distributing "official" patches. Whenever anyone sends out a patch, Geoff decides whether it is a good patch, and if so, distributes it with an official patch level (thus updating newsversion.h or whatever to the new patch level). Others who send out patches should be encouraged to update the patch level to something out of the normal sequence, for instance (note the X): #define NEWS_VERSION "VMS News - V5.9, patch level 6X" That way, no official patch will apply to that version, preventing unofficial patches from creeping into the code and messing up later patches. People applying unofficial patches MUST keep the official patch level source around (or do what I always did, keep the unofficial patch and use patch to remove it before applying the official patch, works just fine). 4) Have someone set up a mail server to supply the patches (the way Larry Wall does for rn, each patch contains instructions on how to get patches from his server). Anyone running PMDF can set up a mailserv to do this. You could have several (wouldn't want to be retrieving all these from Australia to the US!). 5) Distribute the patches as one patch file per directory (i.e. one for source, one for documentation, etc.). These are by far the easiest to apply. You don't really lose anything, as it is easier to fix problems by looking at the reject file than the patches anyway. 6) Distribute patch with NEWS so that everyone will have it to apply patches with. Again, they only have to get it once, and then the patches to news will also include patches to patch (if any) to keep it up to date. That way you know that the version of patch being used is the last one you sent out, and you can test the patch process before shipping the patch. 7) Only post new base levels when the amount of changes in a patch is so big that it is just as easy, or when the accumulated number of patches is unwieldy. People can always get a current patch level version from an archive. There is no reason for archives to maintain base versions, so they would presumably always have all patches installed. 8) I don't think any major changes to the build procedure are needed, as it works quite well. -- Terry Poot (800)255-2762, in Kansas (913)776-4041 The McCall Pattern Company, 615 McCall Rd., Manhattan, KS 66502, USA UUCP: rutgers!ksuvax1!mccall!tp Internet: tp%mccall@ksuvax1.cis.ksu.edu