erf@progress.COM (Eric Feigenson) (12/20/90)
I'm running C-News patched through 1-Dec-1990, on an
Intel UNIX System V/386 Release 3.2 and have a couple of
questions:
(1) We got a version ctl message, and the mail reply failed. This happened
because /bin/mail is stupid on this system, and it couldn't figure
out version@uunet.uu.net as an address. I changed ctl/version to
use mailx (which should work, but newsrun hasn't run yet). There have
been other problems where C-News scripts call mail, but should call
mailx. For example, when it sends mail from newswatch, it will only
mail to users on the local machine. I once tried replacing /bin/mail
with mailx, with disasterous results. Does anyone have any nice
general solution to this problem?
(2) This is about applying patches... I had to change spacefor so that
it works on this system (no surprise there). When I install after
a patch, it overwrites spacefor, so I have to manually make that
change again. This also relates to (1) where I've made other little
tweaks here and there to make things work better in our environment.
Is there something I'm unaware of in the patch/install process that
would inhibit installing over something that I've changed and alert me
so that I don't have to tax my feeble brain and remember exactly where
I've made changes? I admit it; I'm lazy.
Any and all help would be appreciated, especially with the mail problem.
/bin/mail on this system is depressingly stupid, and /usr/bin/mailx has some
problems of its own. Information from anyone with direct experience in
this environment would be especially welcome.
Happy Holidays!
-EricF
--
Eric R. Feigenson UUCP: mit-eddie!progress!erf
Progress Software Corp. Internet: erf@progress.com
5 Oak Park
Bedford, MA 01730henry@zoo.toronto.edu (Henry Spencer) (12/30/90)
In article <1990Dec20.150245.28078@progress.com> erf@progress.COM (Eric Feigenson) writes: >(1) We got a version ctl message, and the mail reply failed. This happened > because /bin/mail is stupid on this system, and it couldn't figure > out version@uunet.uu.net as an address... This is why (a) build asks whether your mailer understands "@", and (b) doc/interface explicitly discusses the demands C News places on mail. One fix for difficulties with this is to place a shell file named "mail" at a suitable place in the news search patch -- e.g. NEWSBIN -- so that the news software gets that rather than your system "mail". > Is there something I'm unaware of in the patch/install process that > would inhibit installing over something that I've changed and alert me > so that I don't have to tax my feeble brain and remember exactly where > I've made changes? I admit it; I'm lazy. This is a difficult problem, and one that we unfortunately have no magic solution for. Maintaining local modifications in the presence of patches that (necessarily) assume unmodified software is just plain awkward. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
woods@eci386.uucp (Greg A. Woods) (01/04/91)
[ This (long) article addresses a much wider problem, and thus I've cross-posted it to comp.sources.d and comp.unix.programmer. Perhaps followup's should be re-directed too, but I'll let someone else do that! ] In article <1990Dec30.032132.10805@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > In article <1990Dec20.150245.28078@progress.com> erf@progress.COM (Eric Feigenson) writes: > > Is there something I'm unaware of in the patch/install process that > > would inhibit installing over something that I've changed and alert me > > so that I don't have to tax my feeble brain and remember exactly where > > I've made changes? I admit it; I'm lazy. > > This is a difficult problem, and one that we unfortunately have no magic > solution for. Maintaining local modifications in the presence of patches > that (necessarily) assume unmodified software is just plain awkward. Well, depending upon the extent of the local modifications, it *can* be quite easy, iff you are using a version control system such as SCCS or RCS. Depending upon the divergence of the local and original sources, often patch can deal with the differences, and where conflicts arise, the reject files show the problems. However, for more complex changes, as long as the file structure remains similar, SCCS and RCS can merge versions and identify conflicts. On my currently dead machine I had modified 99% of the shell scripts, all of the Makefiles, and even some of the documentation, but hardly any of the C code (only one bug fix, I think). However, I still have the original versions of any modified files as SCCS delta 1.1, and all files I had modified were checked out as branches 1.1.1.1. If I want to install a patch to a modified file, I first delta my changes back to 1.1.1.1, then 'get -e' 1.2 from 1.1, and patch it, then delta it back; then I 'get -e' 1.2.1.1, merging 1.2 and 1.1.1.1 (i.e. with '-i1.2,1.1.1.1'), which would hopefully be the new version *with* my local changes already merged in. If there are no conflicts, I delta it back and I have the patch installed, with my changes. If there are conflicts, I edit before delta'ing. I can even use the %R% (release) numbers to identify completely different versions of files where merging would not be practical. This process can easily work for multiple files, thus patching a whole "system" at once, and can work for multiple simultaneous patches too. BTW, I use Allman's sccs, thus Makefiles don't need any changes, since all of the current working versions for all files remain checked out in the same relative place as the originals. The only thing to be aware of is that local SCCS SID's have no direct relation with patch numbers/dates, and even vary between files. I do not create an s. file for everything in a "system", but only for locally modified bits. Patches get installed in original, un-modified files with no local change history. In fact, with SCCS major deltas can be deleted after the merged version is delta'ed, since all it does is take up space. The original patch, if kept, can reproduce it from the current major version (i.e. 1.2). Just before the lightning strike I was in the process of tearing apart all of the patches beyond my current patch level, separating those for the C code changes, and the changes for the scripts, etc. My intention was to patch all of the C code with right away, since I reasoned that the fixes there-in would be most valuable, and the number of conflicts would be few. There also seemed to be little inter-dependence between the changes in the C and changes in the scripts. This was exceedingly tedious work, but I didn't want to think about it enough to automate it. I wanted to be able to (test and) install the C code patches in advance of the script patches. Then I would go back check out the original versions of the scripts, patch them, then merge my branch changes back in, being very careful to heed SCCS's warnings about conflicts, and also being very careful to read each script after patching it, to be sure it still did what *I* wanted it to do. By patching the original, then re-applying my changes, it should be at least close to being correct. The subsequent checks and read-through would verify the new version. The main reason I had not installed the most recent 6 or 8 patches was that my system was running solid without any direct attention to news administration for months, and it seemed no new features in patches up to last August were of sufficient importance to make the change. I believe it was/am at 13-Nov-1989. The primary change I made to almost every script and Makefile in C News was to eliminate the use of 'subst', which massively messes up any attempt to use SCCS or RCS, since it modifies "production" versions of scripts prior to installation. I now use a new subst as a filter on a '.sh' file, dropping the extension to create the installed version. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL