removing stale files

Paul Richards paul at
Thu Jun 12 01:36:09 PDT 2003

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

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]

More information about the freebsd-arch mailing list