From owner-cvs-src@FreeBSD.ORG Sun Jul 24 18:36:18 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 9E84B16A41F; Sun, 24 Jul 2005 18:36:18 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from eastrmmtao03.cox.net (eastrmmtao03.cox.net [68.230.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE0C643D4C; Sun, 24 Jul 2005 18:36:17 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by eastrmmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050724183609.TNCE11541.eastrmmtao03.cox.net@mezz.mezzweb.com>; Sun, 24 Jul 2005 14:36:09 -0400 Date: Sun, 24 Jul 2005 13:37:19 -0500 To: "Maxime Henrion" References: <200507231942.j6NJgdks037508@repoman.freebsd.org> <42E2A029.1090404@gmail.com> <42E2DA50.2000205@FreeBSD.org> <20050724011629.GK14567@elvis.mu.org> <20050724094522.GL14567@elvis.mu.org> From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20050724094522.GL14567@elvis.mu.org> User-Agent: Opera M2/8.01 (Linux, build 1204) Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Doug Barton 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 18:36:18 -0000 On Sun, 24 Jul 2005 04:45:23 -0500, Maxime Henrion wrote: > Jeremy Messenger wrote: >> On Sat, 23 Jul 2005 20:16:29 -0500, Maxime Henrion >> wrote: >> >> >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 >> >> I agree about find(1) isn't right solution, because I still have to >> re-run >> the installworld after I use my script. It's not perfect, but at least >> it >> works for me since around FreeBSD 5.0 to clean up stuff very well. >> >> >IIRC, there are corner cases where it doesn't work. Unless I'm >> >missing something, >> >> Can you point me what's not work? I am insteresting to fix my own script >> if I don't notice anything that don't work. > > There are plenty of cases where a find(1) based mechanism is useless and > I can think of a few. > > If files are installed using the -p flag of install(1), which preserves > the modification time (I'm not sure we actually use this flag). Maybe, it's why I rather to have to re-run the installworld after using delete.sh. > Also, a find -ctime +1 is only useful if the installworld was done > not long ago; if it's a few days old or more, we'd have to hack the > script. Of course, this script is for me mostly...and '-ctime +1' is perfect for me. :-) > We can also imagine > doing an installworld in the morning, and another in the evening. Your > script would fail to find any files to remove, for the same reasons. Yeah that's right, unless someone tweak it. Not great for someone that do a random of update daily. > In short, such a mechanism is way too fragile in my opinion. The system > I'm advocating would have made my life easier in many different > scenarios, some of which a find(1) based one can't handle. Imagine you > do a buildworld, then an installworld, and realised you built the > profiling libs which you don't need. With a system similar to what I'm > suggesting, you can just re-run an installworld with NO_PROFILE=yes and > by doing a diff between the old installworld generated file and the new > one, you'll get precisely the list of the profiling libs to remove. Do anyone know other good trick than use static method or use find(1)? >> >a find(1)-based mechanism couldn't handle directories either. >> >> It can. The '-delete' will remove directory too. Unless, I don't >> understand what you are trying to say what's not work. > > As for directories, I thought their modification time wasn't changed > even when files were copied into it, is it? ==================================== # ls -l /usr/share/doc/ total 18 drwxr-xr-x 2 root wheel 512 Jul 22 17:16 IPv6/ drwxr-xr-x 2 root wheel 512 Jul 22 17:16 atm/ drwxr-xr-x 4 root wheel 512 Jul 22 17:16 bind9/ drwxr-xr-x 2 root wheel 512 Jul 22 17:15 ncurses/ drwxr-xr-x 2 root wheel 2048 Jul 22 17:16 ntp/ drwxr-xr-x 2 root wheel 512 Jul 22 17:16 papers/ drwxr-xr-x 23 root wheel 512 Jul 22 17:16 psd/ drwxr-xr-x 13 root wheel 512 Jul 22 17:16 smm/ drwxr-xr-x 13 root wheel 512 Jul 22 17:16 usd/ ==================================== It seems do it. I personal haven't done any homework for how and when directory time will change. Maybe can add something like 'find ${moo} -type d -empty -delete' (untest) for an extra check. Cheers, Mezz > Cheers, > Maxime -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org