alan@numm.nu.oz (Alan Hargreaves) (07/17/89)
I wouldn't really call this a bug, more of a minor hassle that took me a few days to track down. I just applied the 7-Jul-89 patch and had finished building and installing it. (An important aside, we have another directory to add to the search path, ie /local). The Problem: relaynews had no write access to $NEWSCTL to create a lock file. The Source of the problem: $NEWSPATH in $NEWSCTL/bin/config differed to what was compiled into config.o in libcnews.a. I had originally appended /local to $NEWSPATH. When I rebuilt and installed it I prepended it. The installation then said "Oh, there is already a $NEWSCTL/bin/config. I wont rewrite it". Thus when setdirs() was called from relaynews, it said "Oh, NEWSPATH isn't what I expected, call unprivileged() and run thus". So, make sure that libcnews/Makefile and $NEWSCTL/bin/config agree about what the environment vars should be. alan. -- Alan Hargreaves (vk2mgl) SysCleric alan@numm.nu.oz Phone: (049) 685 597 SNAIL: c/- Computing Centre, University of Newcastle, NSW 2308, Australia. Brisley's Definition: numm.nu.oz: A dying machine in a sea of first year students.
henry@utzoo.uucp (Henry Spencer) (07/21/89)
In article <1989Jul17.045108.8677@numm.nu.oz> alan@numm.nu.oz (Alan Hargreaves) writes: >When I rebuilt and installed it I [changed] it. The installation >then said "Oh, there is already a $NEWSCTL/bin/config. I wont rewrite >it". Thus when setdirs() was called from relaynews, it said "Oh, NEWSPATH >isn't what I expected, call unprivileged() and run thus". Sigh. This particular problem is arguably not the software's fault, but there is a more general one here. The installation stuff does deliberately refuse to overwrite existing files... but what if you're re-installing it and *want* those files overwritten? I'm going to have to look at this. Probably what is wanted is a separation between two classes of control files, the ones that are supplied only as samples and will certainly have to be customized locally (and hence should not be overwritten with new copies of the samples), and the ones that are supplied/built as real parts of the software and should change when it does. -- $10 million equals 18 PM | Henry Spencer at U of Toronto Zoology (Pentagon-Minutes). -Tom Neff | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
woods@eci386.UUCP (07/22/89)
In article <1989Jul20.181937.19387@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > Sigh. This particular problem is arguably not the software's fault, but > there is a more general one here. The installation stuff does deliberately > refuse to overwrite existing files... but what if you're re-installing it > and *want* those files overwritten? I'm going to have to look at this. The obvious solution (to me) is to never modify the "installed" version of the files. I've managed several systems where ALL configuration files which were never programme modified (i.e. not /etc/passwd) were kept in a source tree, and managed with SCCS (and sccs). A great example of where this is useful, even if the value of the version history is questionable are the configuration files and scripts in /usr/lib/uucp/*. In fact I even used this methodology with both alpha and beta C News. This scheme requires a bit more dicipline (and work). SCCS (or RCS) could be used on the config files in their installed locations, however by keeping them in the source tree, you have far fewer backup, etc. problems. You are less likely to tromp on a file with your editor, and if you do, there's always the version database to fall back on. This job is made much easier if the Makefiles are fixed to do the installations properly (i.e. with su -c's, etc.) and the configuration dependent parts of the Makefiles are put either in a master (super) Makefile, or in a master include done by each Makefile, or both. I got sufficiently frustrated with the installation of the new C News to begin setting this up again. I'm confident my effort won't be trashed when I have to re-install it 'cause of a major re-write down the line. [1/2 :-), 'cause the alpha, beta, and distributed versions have all been sufficiently different to require a repeat of this work.] I definitly will not attempt to upgrade eci386 (running beta C News) before this is done (on my home machine: robohack). -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA