Date: Fri, 09 May 2003 11:28:36 -0700
From: Tim Kientzle <kientzle@acm.org>
To: Paul Richards <paul@freebsd-services.com>
Cc: "M. Warner Losh" <imp@bsdimp.com>
Subject: Re: hardcoded -C argument to ${INSTALL}
Message-ID: <3EBBF354.4010005@acm.org>
References: <3EB8109D.2060307@isi.edu> <20030507083913.Y18014@gamplex.bde.org> <p0521060abaddf1caa9fc@[128.113.24.47]> <20030506.222443.09095788.imp@bsdimp.com> <20030509103425.GN1869@survey.codeburst.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EBBF354.4010005>