7. Ограничения

Автоматизированная установка порта может оказаться затруднена, если он является интерактивным и не поддерживает команду make BATCH=YES install. Для нескольких портов интерактивность означает не более, чем ввод yes в ответ на вопрос о принятии некоторого лицензионного соглашения. Если такой ввод считывается со стандартного устройства ввода, мы просто направляем соответствующие ответы на вход установочной команды (обычно make install; именно так я работал с java/linux-sun-jdk14 в stage_2.conf.default).

Такой подход, например, не работает с editors/staroffice52, который требует работы X11. Процедура установки включает достаточно большое количество нажатий мыши и набор, так что она не может быть автоматизирована так, как другие порты. Однако для меня сработал следующий трюк: сначала я создал пакадж staroffice на старой системе при помощи команды

# 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'

и на втором этапе я просто использовал следующее:

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

Вы должны также принять во внимание вопросы обновления конфигурационных файлов. Вообще говоря, вы не знаете, когда и сменился ли вообще формат или содержимое конфигурационного файла. В файл /etc/group может быть добавлена новая группа, или в /etc/passwd может добавиться дополнительное поле. Всё это уже происходило в прошлом. Простое копирование конфигурационного файла из старой в новую систему может в большинстве случаев оказаться достаточным, но в этих случаях это не так. Если вы обновляете систему каноническим способом (путём перезаписывания старых файлов), вы должны использовать утилиту mergemaster для работы с изменениями, если вы хотите эффективно объединить вашу локальные настройки с потенциально новыми возможностями. К сожалению, mergemaster работает только с файлами базового комплекта системы, а не с любыми файлами, устанавливаемыми портами. Похоже, что стороннее программное обеспечение специально проектируется для того, чтобы я не дремал, и меняет конфигурационные файлы по два раза в месяц. Для обнаружения таких скрытых изменений, я держу копию изменённых конфигурационных файлов там же, где и stage_3.mk и сравниваю результат с помощью правил make. Например, для конфигурационного файла апача, httpd.conf целью будет config_apache.

@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

Если разница между файлами несущественна я могу выполнить cp /usr/local/etc/apache2/httpd.conf httpd.conf.

Я использовал систему FreeBSD From Scratch несколько раз для обновления 5-CURRENT до 5-CURRENT, то есть я никогда не пытался установить 5-CURRENT из системы 4-STABLE и наоборот. Из-за количества изменений между релизами с разными старшими номерами я ожидаю, что этот процесс будет несколько более сложным. Использование FreeBSD From Scratch для обновления внутри 4-STABLE должно проходить безболезненно (хотя я ещё этого не пробовал делать.) Пользователи ветки 4-STABLE могут иметь в виду следующее:

Замечание: Если вы не используете файловую систему устройств, devfs(5), то можете создать устройства для некоторого вашего оборудования командой MAKEDEV(8) в процессе all_remaining_customization.

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.

Обновлено: 12.03.2015