Date: 06 Jul 2002 03:05:46 +0100 From: Paul Richards <paul@freebsd-services.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: Terry Lambert <tlambert2@mindspring.com>, Sheldon Hearn <sheldonh@starjuice.net>, current@FreeBSD.ORG Subject: Re: Removing perl in make world Message-ID: <1025921146.881.16.camel@lobster.originative.co.uk> In-Reply-To: <p05111736b94be16e068e@[128.113.24.47]> References: <1025862341.1573.40.camel@lobster.originative.co.uk> <20020705095258.GC775@starjuice.net> <1025864161.1573.45.camel@lobster.originative.co.uk> <p05111730b94b6a140d74@[128.113.24.47]> <3D261EA4.ABC3AEC@mindspring.com> <p05111736b94be16e068e@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2002-07-06 at 01:07, Garance A Drosihn wrote: > At 3:33 PM -0700 7/5/02, Terry Lambert wrote: > > > >So, to summarize: > > > > Let me summarize my own position. > > There are a number of files which installworld does install. After > an installworld is done, there may be a number of files on a person's > hard disk which were not put there by the most recent installworld. > > For each of those files, the issue is one of intent. > > 1) Is it there because the administrator explicitly wanted it > to be there, for explicit reasons that may be perfectly valid > even while testing the latest snapshot of current? > 2) or is it left-over cruft from some previous install, and > which is only getting in the way of proper testing? > > If you keep it that simple, instead of writing 200-line summaries > of what is going on (and the possible motivations of everyone), then > the solution is also simple. The above is just a slight variation > from what happens with /etc config files during a new installworld. > > We should not have anything which automatically blows away those > files. We should have an "unmergemaster" script, which will find > those files, and **ASKS THE DEVELOPER** what they want to do for > each of those files (or maybe for each set of files). No automatic > process is going to be 100% right 100% of the time. I think a -current system is something that should be assumed to be a semi-known environment though. Let's start with a premise: No-one running current is using it for anything other than developing FreeBSD. Given that premise, then there shouldn't be anything in /usr outside of /usr/local, that wasn't put there by make world. Likewise the same should be true of /sbin and /bin. Therefore running, find $listofdirs -newermt $date -delete should be perfectly OK since it's only going to clear out old files that are no longer part of FreeBSD (where $listofdirs is directories that should not be touched other than by make world, and $date is the date of the last install). The only tweak that is necessary is in the case of /usr/lib, where files should be moved to a compat dir and not deleted. I do this periodically on my dev box and it does show up issues. I think it's something we should build into our infrastructure as a step towards a better known environment for testing -current. -- Paul Richards | FreeBSD Services Ltd | Order 4.6 on DVD now. http://www.freebsd-services.com | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1025921146.881.16.camel>