Date: Wed, 11 Jun 2003 14:06:32 -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: <20030611210632.GA695@athlon.pn.xcllnt.net> In-Reply-To: <p05210614bb0d30155a2e@[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]> <20030611190615.GA15695@dhcp01.pn.xcllnt.net> <p05210614bb0d30155a2e@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> Many suggestions amount to removing anything
> "which looks old", because "if it is old, it must be bad".
That's not a good way to approach it.
> That means you're removing files when you don't really know
> what they contain, or why they're there.
Which is bad, because it means you don't know your own source
tree.
> Or you remove files which *you* don't need, but someone else
> will need because they are running freebsd with different
> build options.
Staleness is not a property that is affected by build options.
Hence, the removal of stale files should not be made conditional
upon build options.
To help out in those cases where parts of our tree aren't built
and installed and the user builds and installs off-tree substitutes
(which means that ownership of files is messed with), you suppress
the wholesale removal of stale files. Those users can be expected
to manually remove stale files...
> Once you know that a file is indeed a stale file from a
> previous freebsd install, then it's pretty clear that it
> should be deleted.
Precisely. That's what this discussion is (should be) all
about. We should never delete anything that isn't or wasn't
ours. The past tense here is to plug the philosophical hole
that if a file is stale, it's not ours anymore and removing
it violates the premise that we should not remove files we
don't install. :-)
> If there are bugs with backwards-
> compatibility, then we fix the bugs. I am not concerned
> with those bugs, I am concerned that the utility might
> remove files that we had no business removing.
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.
Thus: my commit that causes a file to become stale should
include the logic to remove the stale file. On top of that
we should make sure that we keep track of those build rules
so that we can remove them after some next release. You
don't want to keep the logic to remove some stale file
forever...
> 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?
> I'm just saying that a utility with a list of specific files is
> much less likely to blow off some poor user's foot when they
> run it.
True. The easiest utility is a a simple for loop as the last
action of installworld, like:
Index: Makefile.inc1
===================================================================
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.365
diff -u -r1.365 Makefile.inc1
--- Makefile.inc1 8 Jun 2003 04:15:05 -0000 1.365
+++ Makefile.inc1 11 Jun 2003 21:04:41 -0000
@@ -409,6 +409,12 @@
done
cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}
rm -rf ${INSTALLTMP}
+.for F in ${STALE_FILES}
+ rm -f $F
+.endfor
+.for D in ${STALE_DIRS}
+ rmdir $D || true
+.endfor
#
# reinstall
--
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?20030611210632.GA695>