7 Limitations

The automated installation of a port may prove difficult if it is interactive and does not support make BATCH=YES install. For a few ports the interaction is nothing more than typing yes when asked to accept some license. If such input is read from the standard input, we simply pipe the appropriate answers to the installation command (usually make install; this is how I deal with java/linux-sun-jdk14 in stage_2.conf.default).

This strategy for example does not work for editors/staroffice52, which requires that X11 is running. The installation procedure involves a fair amount of clicking and typing, so it cannot be automated like other ports can. However the following workaround does the trick for me: first I create a staroffice package on the old system with

# cd /usr/ports/editors/staroffice52
# make package
===>  Building package for staroffice-5.2_1
Creating package /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz
Registering depends:.
Creating bzip'd tar ball in '/usr/ports/editors/staroffice52/staroffice-5.2_1.tbz'

and during stage two I simply use:

# pkg_add /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz

You should also be aware of upgrade issues for config files. In general you do not know when and if the format or contents of a config file changes. A new group may be added to /etc/group, or /etc/passwd may gain another field. All of this has happened in the past. Simply copying a config file from the old to the new system may be enough most of the time, but in these cases it was not. If you update a system the canonical way (by overwriting the old files) you are expected to use mergemaster to deal with changes where you effectively want to merge your local config with potentially new items. Unfortunately, mergemaster is only available for base system files, not for anything installed by ports. Some third party software seems to be especially designed to keep me on my toes by changing the config file format every fortnight. To detect such silent changes, I keep a copy of the modified config files in the same place where I keep stage_3.mk and compare the result with a make rule, e.g. for apache's httpd.conf in target config_apache with

@if ! cmp -s /usr/local/etc/apache2/httpd.conf httpd.conf; then \
    echo "ATTENTION: the httpd.conf has changed. Please examine if"; \
    echo "the modifications are still correct. Here is the diff:"; \
    diff -u /usr/local/etc/apache2/httpd.conf httpd.conf; \
fi

If the diff is innocuous I can make the message go away with cp /usr/local/etc/apache2/httpd.conf httpd.conf.

I have used FreeBSD From Scratch several times to update a 5-CURRENT to 5-CURRENT, i.e. I have never tried to install a 5-CURRENT from a 4-STABLE system or vice versa. Due to the number of changes between different major release numbers I would expect this process to be a bit more involved. Using FreeBSD From Scratch for upgrades within the realm of 4-STABLE should work painlessly (although I have not yet tried it.) Users of 4-STABLE may want to consider the following areas: