Re: RFC: automated way of removing old base system files (only for a recent 6-current!)

From: Willem Jan Withagen <wjw_at_withagen.nl>
Date: Mon, 25 Oct 2004 13:59:36 +0200
Alexander Leidinger wrote:

> Zitat von Thomas Hurst <tom.hurst_at_clara.net>:
> 
> 
>>* Alexander Leidinger (Alexander_at_Leidinger.net) wrote:
>>
>>
>>>But mtree doesn't has an option to ask the user if he really wants to
>>>delete those files (at least it's not very obvious if you fast-read
>>>the man-page). Even if they are old base system files, I don't want to
>>>just remove them without explicit permission. Better safe than sorry.
>>>But maybe I'm paranoid (at least for files and directories, but I
>>>strongly discourage the automated removal of old libs).
>>
>>Can you move them to another directory like portupgrade?  Then just
>>leave it up to the user to clean out lib/compat/old or so?
> 
> 
> Libraries which get removed this way are supposed to appear as an comapt
> distribution of some kind... e.g. ports/misc/compat4x. So the intended way
> of operation would be to either install the compat port and remove the old
> libs, or to reinstall every port with the right dependencies to the new
> libs and remove the old libs.
> 
> Warner and I are talking how to implement the "remove the old libs" step. My
> approach allows a "run and abort if necessary" behavior, while Warners
> suggestion is a "fire and get burned if you forgot something" scenario (you
> could have a look at the files which specify what is supposed to get removed,
> but this view isn't filtered and additionally you have to know where the
> filelist is stored).

Dagerous remark, but.....

Why don't you do it the M$-way, and move al that is to be delete to the side 
somewhere, and inform the user about the location. Het then himself can either 
retrieve what he should not have deleted, or after due time delete it himself?

That would make Warners approach not quite as dramatic as you make it sound.

--WjW
Received on Mon Oct 25 2004 - 09:59:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:19 UTC