Date: Thu, 12 Jun 2003 09:36:04 +0100 From: Paul Richards <paul@freebsd-services.com> To: Doug Barton <DougB@FreeBSD.org> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: removing stale files Message-ID: <20030612083604.GV26927@survey.codeburst.net> In-Reply-To: <20030611144115.E26376@12-234-22-23.pyvrag.nggov.pbz> References: <20030610124747.A7560@phantom.cris.net> <20030610024524.D23396@znfgre.qbhto.arg> <20030611.093203.26943899.imp@bsdimp.com> <20030611190615.GA15695@dhcp01.pn.xcllnt.net> <20030611210632.GA695@athlon.pn.xcllnt.net> <20030611144115.E26376@12-234-22-23.pyvrag.nggov.pbz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 11, 2003 at 02:49:02PM -0700, Doug Barton wrote: > FWIW, I want to express strong support for Garance's caution here, and > Warner's request that this feature NOT be made automatic. More specific > comments inline below. > > > On Wed, 11 Jun 2003, Marcel Moolenaar wrote: > > > On Wed, Jun 11, 2003 at 04:08:39PM -0400, Garance A Drosihn wrote: > > > At 12:06 PM -0700 6/11/03, Marcel Moolenaar wrote: > > > >As for the argument that removing a library, binary or header > > > >may break some tools, scripts or sources that depend on it: > > > >If that happens, we failed to maintain backward compatibility. > > > >The bug is not in the removal of a stale file, but in the > > > >fact that the file has become stale. Keeping stale files > > > >around only hides the bug. > > > > > > That isn't quite what I'm concerned about. I just want to > > > be sure that we are *only* removing files when we *know* > > > what they are. > > > > We always know, because we own them. > > The problem is, we don't know if the user has modified them or not. This > is one of the reasons mergemaster exists for /etc stuff. I've thought about this problem quite a lot recently. I got as far as thinking of a possible solution. Basically, we implement some code in install (which NetBSD already has) that registers files as they get installed. This gives you a registry of all files that are owned by the system. When you run the next make world it compares the new list with the old list and removes those that are now obsolete. If the file is a library then it gets moved to a compat dir. Additionally, a scan can be done of installed binaries and a report produced that lists which are still using deprecated libraries. The registry of known files can also be referenced by a tool that reports all files that are not meant to be there i.e. the local user has put them there, and with a suitable tool the user can register their own files in the registry if they want them to become supported by this mechanism. There's no reason this can't be used by ports as well. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030612083604.GV26927>