Что следует принять во внимание перед сборкой пакета

Перед сборкой пакета необходимо решить, будет ли ваш продукт состоять из одного или нескольких пакетов. Обратите внимание, что установка нескольких маленьких пакетов занимает больше времени, чем установка одного большого пакета. Несмотря на то, что создание одного пакета более рационально, это не всегда возможно. Если принято решение собрать несколько пакетов, следует определить, каким образом сегментировать код приложения. В данном разделе представлен перечень критериев, которые необходимо использовать при планировании сборки пакета.

Многие критерии по созданию пакета предполагают компромисс между ними. Удовлетворить все требования в равной степени часто очень сложно. Критерии представлены по степени их важности. Однако эта последовательность служит лишь примерным руководством, и ее можно изменить в зависимости от обстоятельств. Хотя каждый из этих критериев является важным, вопрос о том, как оптимизировать эти потребности для получения хорошего набора пакетов, разработчику предстоит решать самому.

Дополнительные идеи по разработке пакетов содержатся в Глава 6Дополнительные методы создания пакетов.

Пакеты должны иметь возможность удаленной установки

Все пакеты должны допускать удаленную установку. Возможность удаленной установки означает, что администратор при установке пакета может устанавливать его на клиентской системе не обязательно в корневую (/) файловую систему, где выполняется команда pkgadd.

Оптимизация для клиент-серверных структур

Предусмотрите различные типы составов и настроек системного ПО (например, автономная система и сервер) при планировании пакетов. В хорошо спланированном пакете происходит разделение файлов для оптимизации установки на любом типе структуры. Например, содержимое корневой файловой системы (/) и файловой системы /usr должно быть сегментировано для облегчения поддержки серверных настроек.

Разделение на пакеты в соответствии с функциональностью

Пакеты должны быть самодостаточными с четко определенным набором функциональности. Например, в пакет, содержащий UFS, должны входить все служебные программы UFS, и в нем не должно быть никаких двоичных файлов, не относящихся к UFS.

Пакеты должны быть упорядочены в функциональные блоки с точки зрения потребителя.

Разделение на пакеты в соответствии с лицензионным режимом

Помещайте код, требующий лицензионных выплат по договорным соглашениям, в отдельный пакет или группу пакетов. Не распределяйте этот код по большему числу пакетов, чем необходимо.

Разделение на пакеты в соответствии с зависимостями от системы

Сохраняйте зависимые от системы двоичные файлы в отдельных пакетах. Например, код ядра должен находиться в отдельном пакете, а каждая реализуемая архитектура состоять из отдельного экземпляра пакета. Это правило применимо также к двоичным файлам для различных архитектур. Например, двоичные файлы для системы SPARC будут находиться в одном пакете, а файлы для системы x86 - в другом.

Предотвращение перекрытия пакетов

При создании пакетов старайтесь по возможности избегать дублирования файлов. Ненужное дублирование приводит к сложностям в обслуживании и проблемам с версиями файла. Если продукт состоит из нескольких пакетов, постоянно сравнивайте содержимое этих пакетов для выявления дублированных файлов.

Разделение на пакеты в соответствии с локализацией

Элементы локализации должны находиться в отдельном пакете. При идеальном разделении на пакеты все локализации продукта должны поставляться по схеме: одна национальная настройка - один пакет. К сожалению, в некоторых случаях организационные критерии конфликтуют с функциональными критериями и критериями разделения на продукты.

Международные настройки по умолчанию также могут поставляться в отдельном пакете. Такая структура делает возможной изоляцию файлов, необходимые для изменений в локализации, и стандартизацию формата поставки пакетов локализации.