Date: Wed, 11 Jun 2003 14:36:49 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: "M. Warner Losh" <imp@bsdimp.com>, grog@freebsd.org Cc: arch@freebsd.org Subject: Re: removing stale files Message-ID: <p05210613bb0d2187f0dd@[128.113.24.47]> In-Reply-To: <20030611.093203.26943899.imp@bsdimp.com> References: <20030610124747.A7560@phantom.cris.net> <20030610024524.D23396@znfgre.qbhto.arg> <20030611075750.GB57496@wantadilla.lemis.com> <20030611.093203.26943899.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:32 AM -0600 6/11/03, M. Warner Losh wrote: >In message: <20030611075750.GB57496@wantadilla.lemis.com> > "Greg 'groggy' Lehey" <grog@freebsd.org> writes: >: I think we should work towards a policy where we say "these >: directories belong to the system. Don't install your own >: things there until you know exactly what you are doing.". >: That would greatly simplify the job of keeping things up >: to date. > >In the past, it has been suggested that there be a 'make rmobs' rmobs? ... remove obsolete? >target or something similar. I'd strongly oppose a >non-turn-off-able doing this as part of installworld. That's >too dangerous. I've experimented with some automatically >delete obsolete files schemes in the past, and there is >*MUCH* potential for foot shooting and *** ******* to make >it be on by default. I have also tried to implement a few of my own ideas, and often ended up with something that was just too fragile for me to trust. I mean, I knew I could get it to work for *my* system and what *I* need (after some trial-and-error), but I would never trust it enough to recommend that "everyone" could just blindly run it. >NetBSD's approach in etcupdate is based on a master list of >files that have gone away. I think that something small and simple like this is what we should do at first, because it's something we can do in a short amount of time, and still have reasonable confidence that we aren't doing any harm. That's what we are doing with the "oldRC" files, and I think we could easily list some other specific files where we know the user should not still have those files after the upgrade. Out-of-date locale files could be another example. No, a short list won't be a perfect solution, but we can at least look at all the files in that list and say that each file in that list *will* cause trouble if it is not removed. Does the netbsd approach include any "meta-information" in the master list of files which have gone away? Something like "delete this file if __FreeBSD_version > 500113" ? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05210613bb0d2187f0dd>