> [ On Sun, June 21, 1998 at 06:35:27 (-0700), Tim Rightnour wrote: ]
> > Subject: RE: pkg/5617: Apache-1.3.0 package OS configuration not quite ri
> >
> > On 20-Jun-98 Greg A. Woods spoke unto us all:
> > # What I was talking about was creating the patches in the first place.
> > # There are no tools in existance that create patch sets that follow the
> > # guidelines (i.e. one "change" per file, etc.).  This could be done with
> > # CVS, but it would still be *VERY* tedious.  Actually using CVS to try
> > # and manage a pkgsrc module isn't much gain at all.
> > 
> > This is wholly off topic.. but since you brought it up.. (and because it may
> > benefit others attempting to do this)
> 
> I'll try moving this to tech-ports (i.e. everyone please note the Reply-To!).

tech-ports has nothing to do with this discussion. This should be on
tech-userlevel.

> > The other one quickly replaces ifdef __FreeBSD__ with both freebsd and netbsd
> > defs. It is meant to be run on patches.

Please don't do this - the correct way is to test the BSD definition in
<sys/param.h>, and then:

#if (defined(BSD) && BSD >= 199306)
...
#endif

__FreeBSD__ and __NetBSD__ should be used sparingly, and for features
of the respective Operating Systems which are applicable only to
them. Off the top of my head, certain sysctl parameters spring to mind,
getvfsbyname() etc. 

> (Often another *perfect* use for "#ifdef unix"!!!!!! [unless it's a
> 4.4BSD specific feature].)

Can we at least start to use __unix__, please? I do not want to have to
try to explain to imake, for example, to try to compile unix.c, rather
than 1.c. imake is borken, you say? Right. But too much depends on it to
change its behaviour. And, just for the record, I loathe imake with a
vengeance.

> Strictly speaking I disagree quite strongly with the suggestion of
> breaking patches up into one "change" per file.  This is a suitable
> approach only for providing elective fixes.  When providing a change set
> that's self consistent and entirely mandatory then it is much safer to
> generate and use it as one single patch file.

Ahhh, sigh, and I'm usually one of the supporters of the "everything's a
file" philosophy too.