From owner-freebsd-current@FreeBSD.ORG Fri May 9 11:27:23 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95C5137B401 for ; Fri, 9 May 2003 11:27:23 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AD9E43FBF for ; Fri, 9 May 2003 11:27:22 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (big.x.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h49IR6tJ002858; Fri, 9 May 2003 11:27:06 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3EBBF354.4010005@acm.org> Date: Fri, 09 May 2003 11:28:36 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Richards References: <3EB8109D.2060307@isi.edu> <20030507083913.Y18014@gamplex.bde.org> <20030506.222443.09095788.imp@bsdimp.com> <20030509103425.GN1869@survey.codeburst.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: larse@ISI.EDU cc: current@freebsd.org cc: "M. Warner Losh" Subject: Re: hardcoded -C argument to ${INSTALL} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 18:27:23 -0000 Paul Richards wrote: > On Tue, May 06, 2003 at 10:24:43PM -0600, M. Warner Losh wrote: >>I'm still partial to the obsolete file list, like NetBSD does. >>Anything else I wouldn't trust. Of course, such a list still needs to be generated automatically, else it won't be maintained. You have a good point, though: there will always be cases where some files should not be automatically pruned; an "obsolete file list" can be manually edited to handle such edge cases. > I like the idea of modifying install to register parts of the tree > as either in some db file or a package, it's something I've had in > the back of my mind for about 8 years :-) If everything used ${INSTALL}, then you could build a full list of installed files pretty easily by elaborating on this basic idea: INSTALL="echo" make -s install >/var/tmp/install_log The current /usr/src/Makefile already uses tricks like this to manipulate the build process; the bulk of the infrastructure already exists. Once you have complete file lists for each stable version, you can use diff to build the cross-version obsolete file lists (which can then be manually edited and included as part of the source tree). > One issue with this solution > is that last time I looked not everything actually uses install to > install the files. With the above approach, this is not a problem. Such files won't show up in the old-version list or the new-version list, so diff won't declare them obsolete. I so see a couple of issues, none are particularly difficult to handle: * Pre-install cleaning. A few files will always need to be pruned out prior to upgrading. * Post-install cleaning. Most files need to be removed after upgrading. * Deferred cleaning/rollback. For many of the obsolete files, it may be best to rename them in place, e.g., /bin/deadprogram ---> /bin/deadprogram.obsolete A future cleanup of '*.obsolete' is not hard. ;-) I think the cleanup should probably be a separate make target, e.g.: make buildworld make buildkernel mergemaster -p make precleanworld make installkernel make installworld mergemaster make cleanworld Hmmm... "clean" might not be the best name for this operation... Nothing better is coming to mind immediately, though. Having a separate target makes it optional (allowing people to skip it if necessary) and makes it easy to handle as an afterthought. (Q: "I upgraded, now Foo is broken?" A: "Try make cleanworld to remove old cruft") Tim