make delete-old && make delete-old-libs

[b. f.]

Matthew Seaman wrote:
>mikel king wrote:
>> I had a system that was royally borked after upgrading and completing
>> these steps a few years ago. Ever since I have always skipped these
>> steps. Has anyone else experienced any issues with these two steps?
>

What do you mean by "borked"?  If you mean that you had to temporarily
take it out of service while you rebuilt ports and other software, and
adjusted configuration files, well, that is probably to be expected
during a major upgrade.

>make delete-old-libs can cause you much wailing and gnashing of teeth
>if you do it too soon, but usually only when you're doing a major version
>upgrade.  In those circumstances, unless you're careful, all or large
>parts of your software installed from ports will cease to work.  Delete
>the old libraries only once you've finished reinstalling all of your ported software. Major >version upgrades are one of the few times when there will
>be old shlibs to consider deleting, so this is a rare event.

On the whole, I think it is better to remove all of the old files,
libraries, and ports first, and only then rebuild in a clean sandbox,
rather than run the risk of including an old header or linking to an
old base system library that will soon be discarded.  In any event, if
you must keep old ports around, at least temporarily, in most cases
you can still use them if you have the appropriate COMPAT_FREEBSD?
options in your kernel, and the corresponding misc/compat?x ports
installed.  And for other cases you can use libmap.conf(5).  So you
may as well run make delete-old-libs before rebuilding ports.


>
>make delete-old can theoretically cause you grief if you overwrite bits
>of the base system from ports and set corresponding WITHOUT_FOO flags in
>/etc/src.conf.  On the whole, having ports overwrite base is something to
>be avoided unless you have very good reason to do it.
>

Indeed.

>Whether this will sting you or not is an interesting question: it depends
>on developers adding files and directories to the list of old items
>conditionally on defining WITHOUT_FOO type flags in /etc/src.conf.  While
>this has the intuitively attractive behaviour that doing a buildworld cycle removes the >unwanted programs or libraries, unfortunately it doesn't stop
>there.  It will remove your carefully installed ported software the following
>time you do a buildworld cycle.  For this reason, settings in src.conf
>do not generally affect the list of old files and directories nowadays.

This is wrong: they often do.  To see if the files you have may be
affected by options in src.conf, look at
/usr/src/tools/build/mk/OptionalObsoleteFiles.inc, or run 'make
check-old'. And if you are using -CURRENT, be aware that this file is
now being updated.

In any event, make-delete-old-[libs] is interactive, if you have not
defined BATCH_DELETE_OLD_FILES, and you can choose to prevent some
files from being removed on the command-line.  And of course, you are
not obliged to run these targets, but you are probably better off
doing so, or cleaning your base system by other means, to avoid
pollution.  If you've files or links in directories normally reserved
for the base system that you want to preserve, you could just write a
script to use find(1) to look for files, directories, or links that
are older than your freshly-installed files in these directories,
ignore those you want to keep, and delete the rest.  Some parts of the
base system, particularly some header files, are installed with old
timestamps, but you can just run make installworld again after running
your script, and your base system will be then be clean and
up-to-date.


b.