Xref: utzoo news.admin:1377 news.misc:1027 Path: utzoo!yunexus!spectrix!clewis From: clewis@spectrix.UUCP (Chris Lewis) Newsgroups: news.admin,news.misc Subject: Re: Changes to "checkgroups" postings Message-ID: <349@spectrix.UUCP> Date: 21 Dec 87 17:46:27 GMT Article-I.D.: spectrix.349 Posted: Mon Dec 21 12:46:27 1987 References: <2660@arthur.cs.purdue.edu> Reply-To: clewis@spectrix.UUCP (Chris Lewis) Distribution: na Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 99 In article <2660@arthur.cs.purdue.edu> Gene Spafford (spaf@arthur.cs.purdue.edu) wrote: [Gene requested that followups be mailed, but I think this is really symptomatic of a larger and more general problem and bears discussion here] >When the "inet" groups were created, they were given names that fit >into the regular 7-category newsgroup structure of the Usenet. The >arguments for this were that it would be easier to understand the >placement of these groups, and that it would be easier to migrate >individual "inet" groups into the mainstream Usenet if the conditions >were right. Although there is nothing wrong with these goals, the >software is not designed to handle the situation well. With C-news the situation is worse - ANY newsgroup not mentioned in "newsgroups" or "localgroups" files get bitched about. At lsuc I had to add bionet, alt, unix-pc, to., tor, ont, can, and usrgroup newsgroups to the localgroups file. This is what got me thinking about this last week. B-news (but not C-news) checkgroups.sh knows about "comp", "rec" (actually from the distributions header - this is what causes the inet.* problem) etc. and is smart enough to bitch only about them. In addition, neither B-news or C-news checkgroups will handle checkgroups originating from other "domains". We will in general always have problems with checkgroups, and problems with keeping up to date with other "domains" unless we do something about the semantics of checkgroups. We should remove the "USENET" bias from the checkgroups message. What I would suggest is that we implement a method by which checkgroups can handle an arbitrary number of "*.groups" files. This would largely consist of: 1) For each "domain", you have a "group" file: can.groups ont.groups tor.groups usenet.groups (the current newsgroups file) inet.groups spectrix.groups etc. (note: only the usenet and inet groups overlap in top-level name - doesn't matter though) 2) The checkgroups message contains an argument, eg: Control: checkgroups usenet.groups 3) checkgroups concatenates all of the *.group files together when it does its checking against the active file. 4) The contents of the checkgroups message gets written into the "argument" file. Eg: on a "checkgroup usenet.groups", the list of newsgroups gets written into the "usenet.groups" file. (There has to be some sort of safety check to make sure that someone doesn't say "checkgroups inews") 5) checkgroups might as well concatenate all of the "*.groups" file into the "newsgroups" file (so as to not break postnews or Pnews). Advantages: you can use checkgroups on groups other than the standard USENET ones - the "gateways" of the other sets of newsgroups can periodically post checkgroups. Cleans up some rough edges w.r.t. non-USENET checking and Newsgroups file. Doesn't require any changes to anything other than the checkgroups shell file (at least in B2.11, 2.10.3 or 2.10.2, or C-news Alpha). Real simple to install. The same shell file would probably work no matter what version of news is used. Disadvantages: requirement of up-to-date "group" files (eg: hand patching after a local newgroup) - not a big problem - one that C-news can handle automatically without change except to the newgroup script, B-news would require a bit of hacking to the newgroup stuff. (Eg: "newgroup " appends the text of the article into the specified group file) I'm even volunteering to write a new version of checkgroups to do this. Regarding the present problem (why Gene is going back to manually issued checkgroups). Somewhere along the way between 2.10.1 and 2.11 the checkgroups shell file lost the ability to combine the localgroups file with the newsgroups file when it was doing its checking. Made presumably because it no longer requires the SA to pay any attention to localgroups w.r.t. checkgroups. A mistake in my opinion. As an interim hack, rather than lose the utility of the automatic checkgroups message, why don't we take out the stuff in checkgroups that checks distributions, and append localgroups to newsgroups for processing. In fact, why doesn't everybody simply use a slightly hacked up copy of C-news checkgroups? Along with making sure your localgroups file is up-to-date. For those people with inet.* groups and can't/won't upgrade, why don't they simply put an "exit 0" in the beginning of their checkgroups script? Then they can run it manually thru an unmunged copy. Whilst everybody else gets to use the stuff as was originally intended. -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc}!spectrix!clewis [Also: lsuc!clewis in a pinch] Phone: (416)-474-1955