From owner-freebsd-current@FreeBSD.ORG Tue May 6 18:26:48 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 55E1937B401 for ; Tue, 6 May 2003 18:26:48 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 948E043F85 for ; Tue, 6 May 2003 18:26:47 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h471QkVo067905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2003 21:26:46 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h471QjNr067902; Tue, 6 May 2003 21:26:45 -0400 (EDT) (envelope-from wollman) Date: Tue, 6 May 2003 21:26:45 -0400 (EDT) From: Garrett Wollman Message-Id: <200305070126.h471QjNr067902@khavrinen.lcs.mit.edu> To: Garance A Drosihn In-Reply-To: References: <3EB8109D.2060307@isi.edu> <20030507083913.Y18014@gamplex.bde.org> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: current@freebsd.org Subject: Re: hardcoded -C argument to ${INSTALL} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 01:26:48 -0000 < said: > I think this "remove stale pieces" issue is one that we have > to find a decent solution to, because it keeps popping up > every few months (in slightly different contexts), and it's > going to drive us all nuts. ...which is odd because releases have come with mtree files for quite a few years now, and they contain all the information necessary to compute the set difference between two arbitrary releases. It wouldn't take too much programming to add a flag to mtree(8) which implements the `read the spec file and output a list of files which ought to be present' function, and then all you need is sort(1) and comm(1) to determine which files went away for any pair of releases since the mtree files started being distributed (which includes all the ones that matter). Of course, you could just use `mtree' to delete the old files for you, but you have to be very careful when doing that not to delete the user's files, too. -GAWollman