Перед сборкой пакета необходимо решить, будет ли ваш продукт состоять из одного или нескольких пакетов. Обратите внимание, что установка нескольких маленьких пакетов занимает больше времени, чем установка одного большого пакета. Несмотря на то, что создание одного пакета более рационально, это не всегда возможно. Если принято решение собрать несколько пакетов, следует определить, каким образом сегментировать код приложения. В данном разделе представлен перечень критериев, которые необходимо использовать при планировании сборки пакета.
Многие критерии по созданию пакета предполагают компромисс между ними. Удовлетворить все требования в равной степени часто очень сложно. Критерии представлены по степени их важности. Однако эта последовательность служит лишь примерным руководством, и ее можно изменить в зависимости от обстоятельств. Хотя каждый из этих критериев является важным, вопрос о том, как оптимизировать эти потребности для получения хорошего набора пакетов, разработчику предстоит решать самому.
Дополнительные идеи по разработке пакетов содержатся в Глава 6Дополнительные методы создания пакетов.
Все пакеты должны допускать удаленную установку. Возможность удаленной установки означает, что администратор при установке пакета может устанавливать его на клиентской системе не обязательно в корневую (/) файловую систему, где выполняется команда pkgadd.
Предусмотрите различные типы составов и настроек системного ПО (например, автономная система и сервер) при планировании пакетов. В хорошо спланированном пакете происходит разделение файлов для оптимизации установки на любом типе структуры. Например, содержимое корневой файловой системы (/) и файловой системы /usr должно быть сегментировано для облегчения поддержки серверных настроек.
Пакеты должны быть самодостаточными с четко определенным набором функциональности. Например, в пакет, содержащий UFS, должны входить все служебные программы UFS, и в нем не должно быть никаких двоичных файлов, не относящихся к UFS.
Пакеты должны быть упорядочены в функциональные блоки с точки зрения потребителя.
Помещайте код, требующий лицензионных выплат по договорным соглашениям, в отдельный пакет или группу пакетов. Не распределяйте этот код по большему числу пакетов, чем необходимо.
Сохраняйте зависимые от системы двоичные файлы в отдельных пакетах. Например, код ядра должен находиться в отдельном пакете, а каждая реализуемая архитектура состоять из отдельного экземпляра пакета. Это правило применимо также к двоичным файлам для различных архитектур. Например, двоичные файлы для системы SPARC будут находиться в одном пакете, а файлы для системы x86 - в другом.
При создании пакетов старайтесь по возможности избегать дублирования файлов. Ненужное дублирование приводит к сложностям в обслуживании и проблемам с версиями файла. Если продукт состоит из нескольких пакетов, постоянно сравнивайте содержимое этих пакетов для выявления дублированных файлов.
Элементы локализации должны находиться в отдельном пакете. При идеальном разделении на пакеты все локализации продукта должны поставляться по схеме: одна национальная настройка - один пакет. К сожалению, в некоторых случаях организационные критерии конфликтуют с функциональными критериями и критериями разделения на продукты.
Международные настройки по умолчанию также могут поставляться в отдельном пакете. Такая структура делает возможной изоляцию файлов, необходимые для изменений в локализации, и стандартизацию формата поставки пакетов локализации.