I've just realized that there's an unfortunate problem in the way it
is decided whether to install header files during a "make includes"
run.  The following order of events is what just bit me:

- I fetch a set of source tar files from a ftp.netbsd.org mirror
- A header file is updated in the netbsd.org CVS tree
- I build and install the kit I fetched
- I fetch a new set of tar-balls from the mirror site
- I build and install this -- not! -- the build fails

The problem is that since I installed the first kit I fetched _after_
the header file was updated, the copy of it that's installed in my
/usr/include tree has a newer date stamp there than the actually newer
copy in the new source distribution.  Thus, now that I've fetched a
new set of tar files, the installed header file in /usr/include is
newer than the (higher version) one in the source tree, and the new
file is not installed.  The same thing will happen to CVS clients as
well, of course.

Whoops.

I guess the workaround is to always remove the entire /usr/include
tree before running a "make build" -- but wouldn't it be better if the
way the header files are installed were changed so that they always
are installed with the modification date of the source file?

Of course, it might be argued that the /usr/include tree should always
be installed fresh each time anyway -- in which case the "make build"
run should maybe remove the old one?  Or at least rename it out of the
way, as something like /usr/include.old?  On the other hand, this
makes for trouble for people who have header files installed under
/usr/include from other software.  In my own case, I guess I show my
age when I say I've got a /usr/include/X11 subtree...  :-)

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"