cvs commit: src ObsoleteFiles.inc

[Jeremy Messenger]

On Sun, 24 Jul 2005 04:45:23 -0500, Maxime Henrion <mux at FreeBSD.org> wrote:

> Jeremy Messenger wrote:
>> On Sat, 23 Jul 2005 20:16:29 -0500, Maxime Henrion <mux at 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).

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 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org