From owner-freebsd-arch@FreeBSD.ORG Wed Jun 11 14:49:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A677F37B404; Wed, 11 Jun 2003 14:49:04 -0700 (PDT) Received: from rwcrmhc11.attbi.com (rwcrmhc11.attbi.com [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60D1143F93; Wed, 11 Jun 2003 14:49:03 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by attbi.com (rwcrmhc11) with SMTP id <2003061121490301300anddse>; Wed, 11 Jun 2003 21:49:03 +0000 Date: Wed, 11 Jun 2003 14:49:02 -0700 (PDT) From: Doug Barton To: Marcel Moolenaar In-Reply-To: <20030611210632.GA695@athlon.pn.xcllnt.net> Message-ID: <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> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: grog@freebsd.org cc: ache@nagual.pp.ru cc: "M. Warner Losh" cc: arch@freebsd.org Subject: Re: removing stale files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 21:49:05 -0000 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. > That's why files should be removed as part of installworld > and not by some random tool or target. The tricky part is > time: if I cause a file to become obsolete or stale, then > removing it right away is the safest. The longer I wait, > the bigger the chance that the file (name) is reused for > other purposes and thus the lower the certainty that the > file I'm removing is in fact the one that I've made stale. I don't agree with the idea of removing files via installworld, but your point about the dangers of file name reuse is well taken. > > I started some work on what seemed like an obviously-workable > > solution to me, and found that it rapidly gets complicated > > if you want it to be something that *every* freebsd user > > could run without doing damage. Real damage, not "We goofed > > with backward-compatibility" bugs. > > This very much surprises me, because I don't see how you can > mess up if you stick to the fundamentals. Do I have a huge > blind spot? Not a blind spot necessarily, but perhaps you haven't had a lot of experience with the infinite "creativity" of our users. I would say that at bare minimum, IF the community consensus is to do this in installworld, that there be a knob to turn it off. I'd still rather see this functionality in a seperate utility though. Doug -- This .signature sanitized for your protection