Re: buildworld may be unstable tomorrow morning

[Garance A Drosihn <drosih@xxxxxxx>]

At 9:06 AM -0800 3/22/04, Matthew Dillon wrote:
> :Matthew Dillon wrote:
> :>     It's too late tonight, but monday morning I will likely
> :>     be committing a major revamping of the buildworld code...
> :
> : Something that would have helped me a bit would be to have the
> : 'upgrade' target delete /usr/include/* and do a 'make includes'.
> : (I had some stale FBSD headers left after the conversion.)
>
>     I can't think of a single time that I've ever added or modified
>     files in /usr/include other then synchronizing them with the
>     cvs tree...  I've always put custom header files in
>     /usr/local/include.

I have put custom header files in /usr/include from time-to-time,
but maybe I'm just weird that way.  At the moment I forget why.
I think I was testing some patches which would have committed
new files to /usr/include, so I felt it was important to have
them in /usr/include while testing.

>     I think we could safely do this.  What do other people think?

Don't some ports also put files in there?  The main one I'm
thinking off is X11, since it is often installed as "part of
the base system".  [...checking...]  Hmm.  No, I guess that puts
them in /usr/X11R6/include.  Seems to me that at one time I had
some port which put files in /usr/include...

I must admit I just hate the idea of targets blowing away all
of some major high-level directory like /usr/include.  I do
intend to do something for freebsd to make this an option, but
what I want to do is also provide the option of leaving behind
a backup archive of what was there before the destruction.

Something like:
   if [ -n "${SOMEVAR}" ] ; then
      if [ "/dev/null" != "${SOMEVAR} ] ; then
         cd /usr/include && tar czf ${SOMEVAR} .
      fi
      rm -rf /usr/include/*
      #  maybe add a chflags & a second 'rm' here...
   fi

I actually hope to do the same kind of setup for some other
directories, once I set things up some you can safely boot into
single-user mode and "make installworld" without touching any
files in /*bin, /usr/*bin, or /lib.  Based on my adventures
with upgrading sparc64 to 64-bit time_t, I think that is quite
doable.  Whether I can convince everyone else to let me do it
is another story, of course.  I actually want to check two
variables for each major directory, so there is one variable
for each specific major directory (like /usr/include) one way,
and another variable to handle all directories where the first
(directory-specific) variable has not been specified.

All this in my "copious spare time", of course...  So don't
hold your breath for it!

--
Garance Alistair Drosehn            =   gad@xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad@xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih@xxxxxxx