Mike Clarke wrote:

After pondering a bit more over this problem I think I know where the 6.4 stuff may have come from. After I built the base system I copied various useful files from /root on the 6.4 system, including /root/.cshrc which contained a line setting PACKAGESITE to ftp://ftp2.uk.freebsd.org/pub/FreeBSD/ports/i386/packages-6.4-release/All/ and it's quite possible that I ran portinstall -P for some ports before I got round to changing this to point to packages-8.

Yep.  This would stick a fairly hefty spanner in the works.

Considering the vast number of files in /usr/local/bin with links to missing libraries I think my best approach now will be to deinstall ALL my ports and reinstall them again from scratch after deleting everything in /usr/ports/packages and checking that all directories in /usr/local (except etc) have been emptied.

This also is a good move.  Don't forget to treat /compat/linux similarly
to /usr/local if you have any linux stuff installed -- there have been a
lot of changes to the linuxulator newly available in 8.0 which you really
want if you're going to run linux stuff under emulation.  If you strip out 
/compat/linux completely, then under 8.0 you'll get the latest linux-base-f10
by default when you re-install.

When reinstalling ported software, it's a good idea to adopt the following
strategies:

   * Install whatever ports management software you prefer (portupgrade(1),
portmaster(1)) pretty much straight away -- you'll need this to build everything.
   * Look at the list of installed packages on your 6.4 install, and pick
     out the packages that are your end-use applications.  These will mostly
     be leaf packages, but not always.
* You only need to reinstall just those packages -- everything else should be installed automatically as dependencies. This will help you avoid
     installing and outdated build dependencies or otherwise orphaned packages
     which otherwise tend to accumulate on an actively updated system.
   * For the end-use packages you choose, run 'make config-recursive' before
     you start building anything to ensure you've selected all the required
     options.  Or use portmanager(1) which runs you through the config stage
     first of all.  You need to be a bit careful doing this, as toggling an
     option in a port can radically change its dependency list, and may bring
     new sets of options into play.  To resolve that, you'll need to re-run
'make config-recursive' until it no longer prompts you to make any OPTIONS settings. [There's a PR to fix this behaviour in the works, but
     it hasn't been committed yet.]
   * Where there are ports that have compilation flags or knobs that aren't
     controlled through OPTIONS dialogues, then be sure to record any non-
     default settings in /etc/make.conf.  You can use a construct like this
     to only apply settings to specific ports:

.if ${.CURDIR:M*/mail/dkim-milter}
WITH_LIBDKIM_INSTALL=   yes
WITH_LIBDKIM_SHARED=    yes
WITH_VERIFY_DOMAINKEYS= yes
WITH_STATS=             yes
WITH_DNS_UPGRADE=       yes
.endif

     Well known KNOBS should be set globally where you aren't using the
     default setting, eg:

WITH_OPENSSL_PORT=      yes
WITH_BDB_VER=           47
WITH_MYSQL_VER=         51
WITH_OPENLDAP_VER=      24
WANT_OPENLDAP_SASL=     yes
WITH_GECKO=             libxul
WITH_APACHE2=           yes
APACHE_PORT=            www/apache22
WITH_MODPERL2=          yes
PERL_VERSION=           5.10.1

Again, changing these settings can affect the dependency tree and potentially bring new sets of OPTIONS into play, so test repeatedly
     with 'make config-recursive'
   * It's a good idea to run 'make fetch-recursive' or 'portinstall -RF ...'
or 'portmaster -F ...' after sorting out configuration to download any distfiles before trying to build everything, as this is another place where a big build session can blow up while you aren't looking. It's
     not mandatory though.
   * Once everything is configured nicely, it should be possible to just
     run a massive portupgrade(1) or portmaster(1) session unattended to
     build and install everything, without finding that 10 minutes after
you went home the build stopped at an OPTIONS screen and sat there all night... In fact, it is well worth temporarily defining BATCH in
     make.conf or the environment to just accept the defaults for anything
not yet configured during a big build job like this. (But not otherwise. BATCH isn't a good idea for an incremental upgrade IMHO.)

If you follow these guidelines when installing the system you should find
that not only does it make your initial install run smoothly, but it sets
you up well for managing updates to the installed system in the future.

        Cheers,

        Matthew

--
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                 Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                 Kent, CT11 9PW

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to