Перед сборкой пакета необходимо знать, какие файлы следует создать и какие команды выполнить. Необходимо принять во внимание требования вашего приложения к программному обеспечению компьютера, а также потребности вашего клиента. Вашими клиентами являются администраторы, которые будут устанавливать пакет. В данной главе речь идет о файлах, командах и критериях, которые нужно знать и принимать во внимание до начала сборки пакета.
Ниже приведен перечень вопросов, рассмотренных в данной главе.
Ниже приведены карты задач с поэтапными указаниями для сборки и проверки пакетов.
Прикладное программное обеспечение поставляется в виде блоков, называемых пакетами. Пакет - это набор файлов и каталогов, требуемых для работы программного продукта. Пакет обычно разрабатывается и собирается разработчиком приложения после завершения разработки кода приложения. Программный продукт необходимо объединить в один или несколько пакетов для того, чтобы его легче было переносить на распространяемый носитель. После этого программный продукт может быть тиражирован и установлен администраторами.
Пакет - это набор файлов и каталогов в определенном формате. Этот формат соответствует двоичному интерфейсу приложений (ABI), являющемуся частью определения интерфейса System V.
Существуют две категории компонентов пакета:
объекты пакета - файлы устанавливаемого приложения;
контрольные файлы - контролируют, как, куда и при каких условиях устанавливается пакет.
Контрольные файлы также разделены на две категории: информационные файлы и сценарии установки. Некоторые контрольные файлы являются обязательными. Некоторые контрольные файлы являются необязательными.
Перед созданием пакета приложений необходимо создать обязательные и необязательные компоненты, которые будут составлять пакет. После этого можно выполнить сборку пакета с помощью команды pkgmk.
Для сборки пакета необходимо иметь следующее.
Объекты пакета (файлы и каталоги прикладного ПО)
Два обязательных информационных файла ( pkginfo и prototype )
Необязательные информационные файлы
Необязательные сценарии установки
На рисунке ниже описано содержимое пакета.
Перед сборкой пакета необходимо создать следующие компоненты.
Объекты пакета
Эти компоненты образуют приложение. Они могут состоять из следующих элементов.
Файлы (исполняемые файлы или файлы данных)
Каталоги
Именованные каналы
Ссылки
Устройства
Файл pkginfo
Файл pkginfo содержит обязательную информацию о пакете, определяющую значения параметров. В число значений параметров входят краткое название пакета, полное название пакета и архитектура пакета. Для получения дополнительной информации см. раздел Создание файла pkginfo и справочную страницу pkginfo(4).
Есть две справочные страницы с названием pkginfo(1) На первой справочной странице описана команда раздела 1, которая отображает информацию об установленных пакетах. На второй справочной странице описан файл раздела 4, содержащий характеристики пакета. При работе со справочными страницами обязательно указывайте соответствующий раздел справочной страницы. Пример: man -s 4 pkginfo.
Файл prototype
Файл prototype содержит обязательную информацию о пакете. В нем перечислены все компоненты пакета. Для каждого объекта пакета, информационного файла и сценария установки имеется одна запись. Эта запись состоит из нескольких полей с данными, которые описывают каждый компонент, включая его местоположение, атрибуты и тип файла. Для получения дополнительной информации см. раздел Создание файла prototype и справочную страницу prototype(4).
В пакет можно включить четыре необязательных информационных файла:
Определяет предыдущие версии пакета, которые совместимы с данной версией.
Указывает другие пакеты, у которых есть особая связь с вашим пакетом.
Определяет потребность в дополнительном дисковом пространстве на целевом компьютере помимо того, которое требуется для объектов, указанных в файле prototype. Например, дополнительное пространство может понадобиться для файлов, которые динамически создаются во время установки пакета.
Определяет текст сообщения об авторских правах, которое показывается во время установки пакета.
Каждый информационный файл пакета должен иметь запись в файле prototype. Для получения дополнительной информации о создании этих файлов см. раздел Создание информационных файлов.
Сценарии установки не являются обязательными. Тем не менее, можно снабдить пакет сценариями, которые предлагают действия, выполняемые пользователями во время установки пакета. Сценарий установки имеет следующие характеристики.
Сценарий состоит из команд интерпретатора sh.
Права для файла сценария должны быть установлены на 0644.
Наличие в сценарии идентификатора интерпретатора команд ( #! /bin/sh) не обязательно.
Существуют четыре типа сценариев.
Сценарий request
Сценарий request запрашивает ввод от администратора, устанавливающего пакет.
Сценарий checkinstall
Сценарий checkinstall производит специальную верификацию файловой системы.
Сценарий checkinstall доступен только в выпуске SolarisTM 2.5 и совместимых выпусках.
Процедурные сценарии определяют действия, которые выполняются в определенный момент установки и удаления пакета. Можно создать четыре процедурных сценария со следующими заранее установленными именами: preinstall, postinstall, preremove и postremove.
Сценарии действий над классами
Сценарии действий над классами определяют набор действий, которые будут выполняться над группой объектов.
Для получения дополнительной информации о сценариях установки см. раздел Создание сценариев установки.
Перед сборкой пакета необходимо решить, будет ли ваш продукт состоять из одного или нескольких пакетов. Обратите внимание, что установка нескольких маленьких пакетов занимает больше времени, чем установка одного большого пакета. Несмотря на то, что создание одного пакета более рационально, это не всегда возможно. Если принято решение собрать несколько пакетов, следует определить, каким образом сегментировать код приложения. В данном разделе представлен перечень критериев, которые необходимо использовать при планировании сборки пакета.
Многие критерии по созданию пакета предполагают компромисс между ними. Удовлетворить все требования в равной степени часто очень сложно. Критерии представлены по степени их важности. Однако эта последовательность служит лишь примерным руководством, и ее можно изменить в зависимости от обстоятельств. Хотя каждый из этих критериев является важным, вопрос о том, как оптимизировать эти потребности для получения хорошего набора пакетов, разработчику предстоит решать самому.
Дополнительные идеи по разработке пакетов содержатся в Глава 6Дополнительные методы создания пакетов.
Все пакеты должны допускать удаленную установку. Возможность удаленной установки означает, что администратор при установке пакета может устанавливать его на клиентской системе не обязательно в корневую (/) файловую систему, где выполняется команда pkgadd.
Предусмотрите различные типы составов и настроек системного ПО (например, автономная система и сервер) при планировании пакетов. В хорошо спланированном пакете происходит разделение файлов для оптимизации установки на любом типе структуры. Например, содержимое корневой файловой системы (/) и файловой системы /usr должно быть сегментировано для облегчения поддержки серверных настроек.
Пакеты должны быть самодостаточными с четко определенным набором функциональности. Например, в пакет, содержащий UFS, должны входить все служебные программы UFS, и в нем не должно быть никаких двоичных файлов, не относящихся к UFS.
Пакеты должны быть упорядочены в функциональные блоки с точки зрения потребителя.
Помещайте код, требующий лицензионных выплат по договорным соглашениям, в отдельный пакет или группу пакетов. Не распределяйте этот код по большему числу пакетов, чем необходимо.
Сохраняйте зависимые от системы двоичные файлы в отдельных пакетах. Например, код ядра должен находиться в отдельном пакете, а каждая реализуемая архитектура состоять из отдельного экземпляра пакета. Это правило применимо также к двоичным файлам для различных архитектур. Например, двоичные файлы для системы SPARC будут находиться в одном пакете, а файлы для системы x86 - в другом.
При создании пакетов старайтесь по возможности избегать дублирования файлов. Ненужное дублирование приводит к сложностям в обслуживании и проблемам с версиями файла. Если продукт состоит из нескольких пакетов, постоянно сравнивайте содержимое этих пакетов для выявления дублированных файлов.
Элементы локализации должны находиться в отдельном пакете. При идеальном разделении на пакеты все локализации продукта должны поставляться по схеме: одна национальная настройка - один пакет. К сожалению, в некоторых случаях организационные критерии конфликтуют с функциональными критериями и критериями разделения на продукты.
Международные настройки по умолчанию также могут поставляться в отдельном пакете. Такая структура делает возможной изоляцию файлов, необходимые для изменений в локализации, и стандартизацию формата поставки пакетов локализации.
В этом документе приведено описание пакетов SVR4. Если предполагается использование в ОС OpenSolaris, можно воспользоваться пакетами системы IPS (Image Packaging System). В ОС OpenSolaris реализована поддержка пакетов SVR4 и IPS. Система IPS взаимодействует с сетевыми хранилищами и использует файловую систему ZFS. В ОС OpenSolaris доступна возможность публикации существующих пакетов SVR4 в хранилище IPS с помощью команды pkgsend(1).
В следующей таблице представлено сравнение команд для систем пакетирования SVR4 и IPS. Для получения более подробной информации о IPS см. документ Getting Started With the Image Packaging System (Начало работы с системой IPS).
Таблица 1–1 Задачи пакетирования: IPS и SVR4
Задача |
Команда IPS |
Команда SVR4 |
---|---|---|
Установка нового пакета |
pkg install |
pkgadd -a |
Просмотр информации о состоянии пакета |
pkg list |
pkginfo |
Проверка правильности установки пакета |
pkg verify |
pkgchk -v |
Просмотр информации о пакете |
pkg info |
pkginfo -l |
Просмотр списка содержимого пакета |
pkg contents |
pkgchk -l |
Удаление пакета |
pkg uninstall |
pkgrm |
В данном разделе описаны команды, файлы и сценарии, которые можно использовать при разработке пакетов. Все они описаны в справочных страницах и детально рассмотрены в этом руководстве в соответствии с конкретной задачей, которую они выполняют.
В приведенной ниже таблице представлены команды, которые помогут собрать пакет, проверить его, установить его и получить сведения о нем.
Таблица 1–2 Команды для пакетов
Задача |
Команда/ справочная страница |
Описание |
Дополнительная информация |
---|---|---|---|
Создание пакетов |
Создает файл prototype для ввода в команду pkgmk | ||
Создает устанавливаемый пакет |
|
||
Установка, удаление и перенос пакетов |
Устанавливает пакет ПО в систему | ||
Сохраняет ответы на сценарий запроса request |
|
||
Копирует пакеты на распространяемый носитель |
|
||
Удаляет пакет из системы |
|
||
Получение информации о пакетах |
Проверяет целостность пакета ПО | ||
Отображает информацию о пакете ПО |
|
||
Отображает значения параметров пакета |
|
||
Изменение установленных пакетов |
Внедряет новый объект пакета в уже установленный пакет |
Правила разработки процедурных сценариев и Глава 5Практические примеры создания пакета |
|
Удаляет объект пакета из уже установленного пакета |
|
В таблице ниже представлены информационные файлы, помогающие собрать пакет.
Таблица 1–3 Информационные файлы пакета
Файл |
Описание |
Дополнительная информация |
---|---|---|
Файл со значениями по умолчанию для установки пакета | ||
Файл совместимости пакета | ||
Информация об авторских правах пакета | ||
Файл зависимостей пакета | ||
Файл характеристик пакета | ||
Файл описания содержимого пакета | ||
Информационный файл пакета | ||
Файл с информацией о требуемом месте на диске для пакета |
Резервирование дополнительного места на диске на целевой системе |
В приведенной ниже таблице представлены необязательные сценарии установки, которые влияют на процесс установки пакета.
Таблица 1–4 Сценарии установки пакета
Сценарий |
Описание |
Дополнительная информация |
---|---|---|
request |
Запрашивает информацию у установщика | |
checkinstall |
Собирает данные о файловой системе |
Сбор данных о файловой системе с помощь сценария checkinstall |
preinstall |
Выполняет требования клиентской установки перед установкой класса | |
postinstall |
Выполняет требования клиентской установки после того, как все тома установлены | |
preremove |
Выполняет требования клиентской установки перед удалением класса | |
postremove |
Выполняет требования клиентской установки после того, как все классы были удалены | |
Действие над классом |
Выполняет ряд действий над определенной группой объектов |