Date: Sun, 24 Jul 2005 11:45:23 +0200 From: Maxime Henrion <mux@FreeBSD.org> To: Jeremy Messenger <mezz7@cox.net> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Doug Barton <dougb@freebsd.org> Subject: Re: cvs commit: src ObsoleteFiles.inc Message-ID: <20050724094522.GL14567@elvis.mu.org> In-Reply-To: <op.suebs8qb9aq2h7@mezz.mezzweb.com> References: <200507231942.j6NJgdks037508@repoman.freebsd.org> <42E2A029.1090404@gmail.com> <42E2DA50.2000205@FreeBSD.org> <20050724011629.GK14567@elvis.mu.org> <op.suebs8qb9aq2h7@mezz.mezzweb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy Messenger wrote: > On Sat, 23 Jul 2005 20:16:29 -0500, Maxime Henrion <mux@FreeBSD.org> 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). 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. 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. 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. > >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? Cheers, Maxime
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050724094522.GL14567>