From owner-cvs-src@FreeBSD.ORG Sun Jul 24 01:16:30 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ABA216A41F; Sun, 24 Jul 2005 01:16:30 +0000 (GMT) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCFD943D45; Sun, 24 Jul 2005 01:16:29 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id B8D445CADC; Sat, 23 Jul 2005 18:16:29 -0700 (PDT) Date: Sun, 24 Jul 2005 03:16:29 +0200 From: Maxime Henrion To: Doug Barton Message-ID: <20050724011629.GK14567@elvis.mu.org> References: <200507231942.j6NJgdks037508@repoman.freebsd.org> <42E2A029.1090404@gmail.com> <42E2DA50.2000205@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E2DA50.2000205@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src ObsoleteFiles.inc X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 01:16:30 -0000 Doug Barton wrote: > Pawel Worach wrote: > > >While you are at it can you add this one too. > > Done. Please note for next time that you need to add a comment indicating > why the file was removed. This can easily be found from the CVS logs. > > BTW, this is exactly why I don't like this mechanism for cleaning stale > files. This list was, as I predicted it would be, quite literally out of > date when it was committed. This is with all due respect to the effort that > went into producing it. It's the methodology that I'm opposed to here. > > I much prefer the dynamic method suggested by myself, mezz, and others > which scans the directories and compares the ages of the files to a known > value. This not only has the benefit of not needing a static list to > support it, but it also has the benefit of alerting you to pieces left > behind when you (for example) add a NO_FOO knob to your make.conf file to > avoid building part of the world. > > I would really like to see us reexamine the thought process behind this > before we invest a lot more time into the static method. I think that the > dynamic method will buy us more down the road. For what it's worth, I'd love to see a mechanism similar to the following: - We ensure every file installed when doing an installworld gets installed through bsd.*.mk. I thought this was already the case but ru@ told me it's not. - We can then add some kind of special make target, for instance build-files-list that generates a file with all the files going to be installed by installworld. - At installworld time we install this special file somewhere. Then we can easily deduce the obsoloted files by doing a diff. The nice thing is that such a system doesn't depend on people keeping a file up-to-date, and it's safer than the find(1) method because IIRC, there are corner cases where it doesn't work. Unless I'm missing something, a find(1)-based mechanism couldn't handle directories either. Another cool thing is that if you know you installed a system some day, but you don't have the file containing the installed files anymore, you can just do a cvs co -D'thedate' and run make build-files-list. A downside of all this is that it's probably quite computationally expensive. Cheers, Maxime