Date: Wed, 11 Jun 2003 12:06:15 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Garance A Drosihn <drosih@rpi.edu> Cc: arch@freebsd.org Subject: Re: removing stale files Message-ID: <20030611190615.GA15695@dhcp01.pn.xcllnt.net> In-Reply-To: <p05210613bb0d2187f0dd@[128.113.24.47]> References: <20030610124747.A7560@phantom.cris.net> <20030610024524.D23396@znfgre.qbhto.arg> <20030611075750.GB57496@wantadilla.lemis.com> <20030611.093203.26943899.imp@bsdimp.com> <p05210613bb0d2187f0dd@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 11, 2003 at 02:36:49PM -0400, Garance A Drosihn wrote: > > >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. I'm not sure people realize that things are being mixed-up. The removal of, say, stale header files has nothing to do with /etc or configuration. The removal of a header file should be done at installworld time when the new bits that define FreeBSD without said header is being put in place. The same applies to locale files, libraries and binaries. Do not add to the problem space those bits that are handled (or supposed to be handled) by mergemaster. That we don't touch. 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. If breaking the backward compatibility was intentional, then removal of the file is mandatory. FWIW, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030611190615.GA15695>