Re: hardcoded -C argument to ${INSTALL}

Paul Richards wrote:

> On Tue, May 06, 2003 at 10:24:43PM -0600, M. Warner Losh wrote:
>>I'm still partial to the obsolete file list, like NetBSD does.
>>Anything else I wouldn't trust.


Of course, such a list still needs to be generated
automatically, else it won't be maintained.  You have
a good point, though:  there will always be cases where
some files should not be automatically pruned; an
"obsolete file list" can be manually edited to handle
such edge cases.


> I like the idea of modifying install to register parts of the tree
> as either in some db file or a package, it's something I've had in
> the back of my mind for about 8 years :-)


If everything used ${INSTALL}, then you could build
a full list of installed files pretty easily by
elaborating on this basic idea:
    INSTALL="echo" make -s install >/var/tmp/install_log
The current /usr/src/Makefile already uses tricks
like this to manipulate the build process; the bulk
of the infrastructure already exists.

Once you have complete file lists for each stable version,
you can use diff to build the cross-version obsolete
file lists (which can then be manually edited and
included as part of the source tree).

> One issue with this solution
> is that last time I looked not everything actually uses install to
> install the files.


With the above approach, this is not a problem.
Such files won't show up in the old-version list
or the new-version list, so diff won't declare
them obsolete.
I so see a couple of issues, none are particularly
difficult to handle:
  * Pre-install cleaning.  A few files will always
    need to be pruned out prior to upgrading.
  * Post-install cleaning.  Most files need to
    be removed after upgrading.
  * Deferred cleaning/rollback.  For many of
    the obsolete files, it may be best to
    rename them in place, e.g.,
      /bin/deadprogram ---> /bin/deadprogram.obsolete
    A future cleanup of '*.obsolete' is not hard. ;-)

I think the cleanup should probably be a separate
make target, e.g.:
   make buildworld
   make buildkernel
   mergemaster -p
   make precleanworld
   make installkernel
   <reboot>
   make installworld
   mergemaster
   make cleanworld
   <reboot>

Hmmm... "clean" might not be the best name
for this operation...  Nothing better is coming
to mind immediately, though.

Having a separate target makes it optional
(allowing people to skip it if necessary)
and makes it easy to handle as an afterthought.
(Q: "I upgraded, now Foo is broken?"
A: "Try make cleanworld to remove old cruft")

Tim