From owner-freebsd-current  Fri Sep 19 01:12:54 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA23857
          for current-outgoing; Fri, 19 Sep 1997 01:12:54 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA23851
          for <freebsd-current@FreeBSD.ORG>; Fri, 19 Sep 1997 01:12:48 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id RAA07637; Fri, 19 Sep 1997 17:59:33 +1000
Date: Fri, 19 Sep 1997 17:59:33 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199709190759.RAA07637@godzilla.zeta.org.au>
To: asami@cs.berkeley.edu, gurney_j@resnet.uoregon.edu
Subject: Re: Yet Another bug in src/Makefile
Cc: dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> * of course there is good argument that the installed to area should
> * be clean to prevent old files from contaminating a setup...  but
> * if we start to clean out /usr/include, we should also do /{bin,sbin}
> * /usr/{bin,share,sbin,lib,libexec} and any others that get installed...
>
>I agree with you, but the comments at the top of src/Makefile say
>otherwise.

I agree too.  Perhaps the mtree database (bin.mtree in releases) provides
enough information to clean up standard binary directories, and packages
should use an mtree database instead of a home made format.

>Should we just nuke the CLOBBER option entirely, or change 
>the rules so it will actually delete /usr/include/*?

Don't nuke it.  It works as intended for `make includes' run separately
from `make world'.  (`make includes' itself doesn't run quite as intended.
It is missing a few directories in 2.2 and has some problems with libss in
all versions.  Using CLOBBER with `make includes' in 2.2 ensures a few
missing includes unless `make install' is run later to install everything
:-).)

Bruce