Date: Wed, 11 Jun 2003 14:49:02 -0700 (PDT) From: Doug Barton <DougB@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: arch@freebsd.org Subject: Re: removing stale files Message-ID: <20030611144115.E26376@12-234-22-23.pyvrag.nggov.pbz> In-Reply-To: <20030611210632.GA695@athlon.pn.xcllnt.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030611144115.E26376>