Программирование: Разработка и отладка программ

Глава 20. Создание пакетов программного обеспечения для установки

Эта глава посвящена подготовке программного обеспечения к установке с помощью команды installp.

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

Установочный пакет представляет собой файл в формате backup, в который входят собственно файлы программного продукта, управляющие файлы и, иногда, файлы для настройки процедуры установки. Для установки и обновления программных продуктов применяется команда installp.

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

Обновлением или пакетом обновлений называется пакет, при установке которого вносятся изменения в уже установленный набор файлов.

Стандартной системой в этой главе называется любая система, за исключением бездисковых систем.

Эта глава состоит из следующих разделов:

• Требования к процедуре установки
• Требования к управляющей информации
• Требования к компоновке пакетов
• Компоненты установочного пакета
• Формат установочного пакета
• Соглашения о присвоении имен
• Идентификатор уровня набора файлов
• Состав пакета программного обеспечения
• Информационный файл lpp_name
• Библиотечный файл управления установкой - liblpp.a
• Подробное описание файлов управления установкой
• Файлы управления установкой для продуктов с измененной структурой
• Установочные файлы для дополнительных дисковых подсистем
• Формат дистрибутивных носителей
• Файл с таблицей содержимого
• Алгоритм работы команды installp)

Примечание: Начиная с версии 4.3, в AIX встроены дополнительные средства работы с документацией. Если электронная документация по продукту написана в формате HTML, ТО при установке продукта ее можно зарегистрировать в службе поиска документации. В этом случае пользователи смогут просматривать документацию и находить нужную информацию с помощью стандартного системного графического интерфейса. Кроме того, служба поиска документации может вызываться непосредственно из программного продукта, если разработчик предусмотрит такую возможность. Для регистрации информации в службе поиска документации необходимы особые процедуры создания установочного пакета программного продукта. Информация об этом приведена в разделе Глава 21, Documentation Library Service.

Требования к процедуре установки

• Установка должна выполняться без участия пользователя. Если продукт нужно настраивать вручную, то настройка должна выполняться либо до, либо после установки.
• Все зависящие друг от друга наборы файлов и обновления должны устанавливаться одной операцией.
• Процедура установки не должна перезагружать систему. Допускается временное прекращение работы отдельных компонентов системы, а полная перезагрузка, если она все-таки необходима, должна выполняться после завершения установки.

Требования к управляющей информации

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

Требования к компоновке пакетов

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

Компоненты установочного пакета

Для поддержки среды клиент-сервер установочный пакет должен быть разделен на следующие компоненты:

Краткое описание файловых систем

Ниже приведено краткое описание ряда файловых систем и каталогов AIX. Оно поможет вам при разделении пакета на компоненты root, usr и share.

Некоторые каталоги, относящиеся к компоненту root:

Некоторые каталоги, относящиеся к компоненту usr:

Некоторые каталоги, относящиеся к компоненту share:

Формат установочного пакета

Установочный пакет должен представлять собой файл в формате backup, который команда installp сможет восстановить во время установки. Этот файл может поставляться на ленте, дискетах или на компакт-дисках. Информация о формате, в котором установочные пакеты должны быть записаны на носителе, приведена в разделе Формат дистрибутивных носителей.

Соглашения о присвоении имен

Присваивая имена файлам, старайтесь следовать приведенным ниже рекомендациям:

Имя пакета (Пакет) должно начинаться с названия продукта. Имена всех пакетов должны быть уникальны.

Имена наборов файлов должны соответствовать следующему шаблону:

Пакет[[.Группа].Набор]

Если пакет состоит из одного набора файлов, имя набора файлов может совпадать с именем пакета (Пакет).

Группа указывает логическую группу наборов файлов, в которую входит данный набор файлов.

Набор - это произвольное имя набора файлов, которое может включать расширение.

Имя набора файлов должно содержать не менее 2 символов, причем оно может начинаться с буквы или символа подчеркивания (_). В качестве остальных символов могут использоваться буквы, цифры, знаки подчеркивания, точки (.), знаки плюса (+) и минуса (-), восклицательные знаки (!), тильды (~), символы процента (%) и знаки вставки (^). Точка не может быть последним символом в имени набора файлов. Все символы в имени набора файлов должны быть символами ASCII. Длина имени должна быть не более 144 байт. Имена всех наборов файлов в составе пакета должны быть различны.

Соглашения о присвоении расширений наборам файлов

Ниже указаны некоторые стандартные расширения имен для наборов файлов:

Особые соглашения о присвоении имен пакетам с драйверами

Команда cfgmgr (администратор настройки) автоматически устанавливает драйверы обнаруженных в системе устройств, если эти драйверы записаны на установочном носителе. При этом имена драйверов должны быть заданы в следующем формате:

devices.тип-шины.карта

Например, карте Token-Ring для шины Micro Channel в администраторе настройки соответствует идентификатор 8fc8. Соответствующему пакету драйверов должно быть присвоено имя devices.mca.8fc8. Набору файлов с микрокодом для этого пакета соответствует имя devices.mca.8fc8.ucode.

Особые соглашения о присвоении имен каталогам сообщений

В команде installp предусмотрена опция автоматической установки каталогов сообщений. Если эта опция указана в командной строке, то система попытается установить с носителя наборы файлов с каталогами сообщений для основного языка системы.

продукт.msg.язык[.группа]

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

Например, продукт Super.Widget может состоять из групп наборов файлов plastic и metal. Все каталоги сообщений продукта Super.Widget на русском языке могут поставляться в одном наборе файлов Super.Widget.msg.ru_RU. Если для групп наборов файлов plastic и metal требуются разные каталоги сообщений, то они могут поставляться в двух наборах файлов - Super.Widget.msg.ru_RU.plastic и Super.Widget.msg.ru_RU.metal.

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

Имена файлов

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

Идентификатор уровня набора файлов

Обозначение уровня набора файлов

Уровень набора файлов, который также называется уровнем, v.r.m.f или VRMF, задается в следующем виде:

версия.выпуск.уровень-модификации.уровень-исправления[.ИД-исправления]

версия	Номер версии длиной 1 или 2 цифры.
выпуск	Номер выпуска длиной 1 или 2 цифры.
модификация	Номер модификации длиной от 1 до 4 цифр.
уровень-исправления	Номер исправления длиной от 1 до 4 цифр.
ИД-исправления	Идентификатор исправления длиной до 9 символов. Поле ИД-исправления применяется только в обновлениях в формате AIX версии 3.2.

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

Рекомендуется присваивать всем наборам файлов в пакете один и тот же уровень, хотя в пакетах AIX версии 4.1 это не обязательно.

Уровень набора файлов может только возрастать. При проверке версий команда installp полагает, что чем выше уровень, тем новее набор файлов.

Самой старшей считается первая цифра уровня, самой младшей - последняя (то есть, уровень 3.2.0.0 выше уровня 2.3.0.0).

Правила нумерации уровней в наборах файлов AIX версии 4.1

В целях упрощения работы с программным обеспечением в пакетах AIX 4.1 были приняты следующие соглашения по нумерации уровней:

• Базовому набору файлов должен быть присвоен уровень исправления 0 (ноль).
• Базовый набор файлов должен обеспечивать выполнение всех функций, предусмотренных в предыдущих версиях этого же набора файлов. Например, набор файлов Plan.Day уровня 2.1 должен обеспечивать выполнение всех функций набора файлов Plan.Day уровня 1.1.
• Обновлениям должны присваиваться либо ненулевые уровни модификации, либо ненулевые уровни исправления.
• Версия и выпуск обновления должны совпадать с версией и выпуском обновляемого набора файлов.
• По умолчанию обновление с ненулевым уровнем исправления должно обновлять набор файлов той же версии, того же выпуска, той же модификации и нулевого уровня исправления. Если это требование не выполнено, то нужный уровень базового набора файлов должен быть указан в разделе необходимого программного обеспечения в файле lpp_name.
• По умолчанию обновление с ненулевым уровнем модификации и нулевым уровнем исправления должно обновлять набор файлов той же версии, того же выпуска и нулевого уровня модификации. Если это требование не выполнено, то нужный уровень базового набора файлов должен быть указан в разделе необходимого программного обеспечения в файле lpp_name.
• Обновление должно обеспечивать выполнение всех функций, предусмотренных в предыдущих обновлениях того же уровня набора файлов.

Информация о совместимости для обновлений AIX версии 3.2

Во всех обновлениях в формате 3.2 должен быть указан идентификатор исправления. В других видах пакетов идентификатор исправления недопустим.

В именах базовых наборов файлов не должно быть идентификатора исправления.

Идентификатор исправления должен состоять только из символов ASCII. Первым символом идентификатора должна быть буква. Остальными символами должны быть буквы или цифры. В рамках одного продукта все идентификаторы исправлений должны быть уникальными.

Идентификаторы исправлений, начинающиеся с символов U4, зарезервированы для исправлений операционной системы AIX.

Состав пакета программного обеспечения

В этом разделе описаны файлы, входящие в установочные пакеты. Каталоги, в которых находятся эти файлы, зависят от типа установочного пакета. Если в обновлении в качестве одного из компонентов пути указано имя-пакета, то оно заменяется на последовательность имя-пакета/имя-набора-файлов/уровень-набора-файлов(а для обновлений в формате 3.2-> - на последовательность имя-пакета/inst_ИД-исправления, где ИД-исправления - это идентификатор обновления).

В компонент usr установочного пакета входят следующие файлы управления установкой:

• ./lpp_name

В этом файле содержится информация об устанавливаемом или обновляемом пакете. В целях повышения производительности рекомендуем помещать файл lpp_name в начало архивного установочного файла. Дополнительная информация приведена в разделе Информационный файл lpp_name.

• ./usr/lpp/имя-пакета/liblpp.a

В этом архивном файле содержатся управляющие файлы, применяемые для установки или обновления компонента usr пакета программного обеспечения. Дополнительная информация о файлах, хранящихся в этой архивной библиотеке, приведена в разделе Файл управления установкой liblpp.a (Библиотечный файл управления установкой - liblpp.a).

• Архив, в котором содержатся все новые и обновленные файлы, относящиеся к компоненту usr устанавливаемого продукта. Файлы хранятся в этом архиве в виде дерева (с указанием абсолютного пути к каждому из них).

Если в установочном пакете есть компонент root, то в него должны входить следующие файлы:

• ./usr/lpp/пакет/inst_root/liblpp.a

В этом библиотечном файле содержатся управляющие файлы, применяемые для установки или обновления компонента root пакета программного обеспечения.

• Данный файл представляет собой архив, в который входят все новые и обновленные файлы, относящиеся к компоненту root устанавливаемого пакета. Если пакет предназначен для установки базового уровня продукта, то эти файлы должны быть помещены в архив с сохранением относительного пути от каталога ./usr/lpp/Пакет/inst_root.

Если в продукте предусмотрен компонент share, он должен поставляться отдельно от компонентов usr и root, в собственном пакете. Установочный пакет компонента share должен представлять собой файл в формате backup, в котором обязательно должны содержаться следующие файлы:

• ./lpp_name

В этом файле содержится информация о компоненте share устанавливаемого или обновляемого пакета.

• ./usr/share/lpp/Пакет/liblpp.a

В этом библиотечном файле содержатся управляющие файлы, применяемые для установки или обновления компонента share пакета программного обеспечения.

• Архив, в котором содержатся все новые и обновленные файлы, относящиеся к компоненту share устанавливаемого продукта. Файлы хранятся в этом архиве в виде дерева (с указанием абсолютного пути к каждому из них).

Примеры пакетов программного обеспечения

Пакет farm.apps содержит набор файлов farm.apps.hog 4.1.0.0. Набор farm.apps.hog 4.1.0.0 состоит из следующих файлов:

/usr/bin/raisehog (из компонента usr)
/usr/sbin/sellhog
 (из компонента usr)
 
/etc/hog
 (из компонента root)

Пакет farm.apps должен содержать, как минимум, следующие файлы:

./lpp_name
./usr/lpp/farm.apps/liblpp.a
./usr/lpp/farm.apps/inst_root/liblpp.a
./usr/bin/raisehog
./usr/sbin/sellhog
./usr/lpp/farm.apps/inst_root/etc/hog

Предположим, что обновление farm.apps.hog 4.1.0.3 заменяет следующие файлы:

/usr/sbin/sellhog
/etc/hog

В этом случае установочный пакет обновления должен содержать следующие файлы:

./lpp_name
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/liblpp.a
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/liblpp.a
./usr/sbin/sellhog
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/etc/hog

Обратите внимание на то, что файл из компонента root в установочном пакете находится в каталоге inst_root. Файлы, относящиеся к компоненту пакета, зависящему от системы, должны находиться в каталоге inst_root. Эти файлы устанавливаются в корневой файловой системе каждой системы, на которой устанавливается пакет. Фактически они просто копируются в корневую файловую систему из каталога inst_root. Напомним, что компонент usr состоит из файлов, которые могут одновременно использоваться несколькими компьютерами.

Информационный файл lpp_name

Информационный файл lpp_name должен содержаться в каждом установочном пакете. Из файла lpp_name команда installp получает информацию о пакете в целом и обо всех входящих в него наборах файлов. Пример файла lpp_name для пакета с обновлением приведен на следующем рисунке. Цифры и стрелки на этом рисунке соответствуют полям приведенной ниже таблицы.

В следующей таблице приведено описание полей файла lpp_name.

      1 2 3    4
      | | |    |          6      7 89 10     11        12        4 R  S  farm.apps { |      | ||  |     |          |
5 --> farm.apps.hog  04.01.0000.0003 1 N U ru_RU Порося и прочие свиньи # ...
[
13--> *ifreq bos.farming.rte (4.2.0.0) 4.2.0.15
%
14--> /usr/sbin 48
14--> /usr/lpp/farm.apps/farm.apps.hog/4.1.0.3 280
14--> /usr/lpp/farm.apps/farm.apps.hog/inst_root/4.1.0.3.96
14--> /usr/lpp/SAVESPACE 48
14--> /lpp/SAVESPACE 32
14--> /usr/lpp/bos.hos/farm.apps.hog/inst_root/4.1.0.3/ etc 32
15--> INSTWORK 348 128
%
%
16--> вендор-iFOR/LS
17--> ИД-продукта-iFOR/LS
18--> версия-продукта-iFOR/LS
%
19--> IX51366 Свиньи несут яйца.
19--> IX81360 У поросят слишком много ушей.
]
}

Пример файла lpp_name

Раздел с информацией о зависимостях

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

Перед началом установки команда installp сравнивает текущее состояние устанавливаемых наборов файлов с требованиями, перечисленными в файле lpp_name. Если в команде installp указан флаг -g, то все сопутствующие наборы файлов автоматически добавляются в список устанавливаемого программного обеспечения. Наборы файлов устанавливаются в том порядке, чтобы на момент начала установки каждого очередного набора файлов были выполнены все необходимые условия. Непосредственно перед установкой каждого набора файлов команда installp повторно проверяет все условия. Это позволяет гарантировать, что если при установке какого-либо набора файлов возникнет ошибка, то зависящие от него наборы файлов не будут установлены.

В следующих примерах значение требуемый-уровень обозначает минимальный уровень набора файлов, который должен быть установлен в системе. Кроме случаев, когда это явно запрещено, как описано в разделе Информация о заменяемом программном обеспечении, вместо указанного уровня в системе может быть установлен набор файлов более высокого уровня. Например, если в условии указано, что требуется набор файлов plum.tree 2.2.0.0, то при наличии в системе набора файлов plum.tree 3.1.0.0 это условие будет считаться выполненным.

Необходимое программное обеспечение

По умолчанию считается, что для установки обновления требуется, чтобы в системе был установлен базовый уровень этого же набора файлов. Если это условие не должно распространяться на поставляемое вами обновление, вам следует явно задать другое условие. По умолчанию считается, что версия и выпуск базового набора файлов совпадают с версией и уровнем обновления. Если уровень-исправления обновления равен 0, то считается, что модификация и уровень-исправления базового набора файлов равны 0. В противном случае считается, что модификация базового набора файлов совпадает с модификацией обновления, а уровень-исправления базового набора файлов равен 0. Например, по умолчанию для установки обновления уровня 4.1.3.2 требуется, чтобы в системе был установлен набор файлов уровня 4.1.3.0. Для установки обновления уровня 4.1.3.0 требуется, чтобы в системе был установлен набор файлов уровня 4.1.0.0.

Сопутствующее программное обеспечение

Обновляемое программное обеспечение

*ifreq A.obj (1.1.0.0) 1.1.2.3

Если набор файлов A.obj вообще не установлен в системе, то он не будет установлен. Если установлен любой из следующих уровней набора файлов A.obj, то он не будет заменен на уровень 1.1.2.3:

Если установлен любой из следующих уровней набора файлов A.obj, то он будет заменен на уровень 1.1.2.3:

Параметр (установленный-уровень) не обязателен. Если он не указан, то предполагается, что у значений установленный-уровень и требуемый-уровень совпадают версия и выпуск. Если уровень-исправления в значении требуемый-уровень равен 0, то модификация и уровень-исправления установленного-уровня тоже равны 0. В противном случае модификация в значении установленный-уровень равна модификации в значении требуемый-уровень, а значение уровень-исправления равно 0. Пример: если требуемый-уровень равен 4.1.1.1 и не указан параметр установленный-уровень, то установленный-уровень считается равным 4.1.1.0. Если требуемый-уровень равен 4.1.1.0 и не задан установленный-уровень, то предполагается, что установленный-уровень равен 4.1.0.0.

Дополнительное программное обеспечение

Групповое условие

Альтернативный формат условий для совместимости с AIX версий 3.1 и 3.2

Для совместимости с пакетами в формате AIX версии 3.1 и 3.2 требуемый-уровень может быть задан в альтернативном-формате. Альтернативный формат нельзя применять в обновлениях AIX версии 4.1, для установки которых необходим один из предыдущих уровней того же набора файлов.

В альтернативном формате требуемый уровень задается с помощью логических выражений, в которых используются буквы v (версия), r (выпуск), m (модификация), f (уровень исправления) и p (ИД исправления), а также символы <, = и >. Если значение поля удовлетворяет нескольким условиям, то вслед за первым условием указываются альтернативные условия, в которых вместо имени указывается буква o (or, или). Ниже приведен пример условия, указывающего, что необходим набор файлов old.syntax версии 3 и выпуска 2 или выше:

*prereq old.syntax v=3 r=2 o>2

Поскольку команда installp интерпретирует это значение как минимальный допустимый уровень, поле o>2 указывать не обязательно. Следующий пример равносилен предыдущему:

*prereq old.syntax 3.2.0.0

Идентификаторы исправлений, указанные в альтернативном формате, обрабатываются не так, как в версии 3.2. Если в выражении требуемый-уровень содержится какая-либо дополнительная информация, помимо ИД исправления, то новые базовые уровни набора файлов и новые исправления также удовлетворяют заданному условию. (Если это неприемлемо, нужно указать соответствующие ограничения в разделе заменяемого программного обеспечения. Более подробная информация по этому вопросу приведена в разделе Информация о заменяемом программном обеспечении.) Пример: набор файлов old.syntax 1.3.0.0 удовлетворяет следующему условию:

*prereq old.syntax v=1 r=2 p=U412345

В альтернативном формате можно задавать условия на максимальный допустимый уровень набора файлов. Например, следующее условие будет выполнено, если в системе будет установлен набор файлов old.syntax более низкого уровня, чем 1.3.0.0:

*prereq old.syntax v=1 r<3

Примеры информации о зависимостях

1. Следующий пример иллюстрирует применение требований к сопутствующему программному обеспечению. Предположим, что набор файлов book.create 12.30.0.0 не может применяться без наборов файлов layout.text 1.1.0.0 и index.generate 2.3.0.0, и поэтому для набора файлов book.create 12.30.0.0 задано следующее условие:

   *coreq layout.text 1.1.0.0
   *coreq index.generate 2.3.0.0
   

   Набор файлов index.generate 3.1.0.0 удовлетворяет условию index.generate, поскольку уровень 3.1.0.0 выше требуемого уровня 2.3.0.0.

2. В следующем примере применяются несколько условий различных типов. Для набора файлов new.fileset.rte 1.1.0.0 заданы следующие условия:

   *prereq database 1.2.0.0
   *coreq spreadsheet 1.3.1.0
   *ifreq wordprocessorA (4.1.0.0) 4.1.1.1
   *ifreq wordprocessorB 4.1.1.1
   

   К началу установки набора файлов new.fileset.rte в системе должен быть установлен набор файлов database уровня 1.2.0.0 или выше. Если наборы файлов database и new.fileset.rte устанавливаются за один вызов команды installp, то набор файлов database будет установлен до набора файлов new.fileset.rte.

   Набор файлов spreadsheet уровня 1.3.1.0 или выше необходим для работы набора файлов new.fileset.rte. Набор файлов spreadsheet не обязательно устанавливать до набора файлов new.fileset.rte при условии, что оба эти набора файлов будут установлены за один вызов команды installp. Если набор файлов spreadsheet нужного уровня не будет установлен на момент окончания работы команды installp, то будет выдано предупреждение о том, что отсутствует сопутствующее программное обеспечение.

   Если в системе установлен набор файлов wordprocessorA уровня 4.1.0.0 (или он устанавливается вместе с набором файлов new.fileset.rte), то будет установлено обновление wordprocessorA уровня 4.1.1.1 и выше.

   Если в системе установлен набор файлов wordprocessorB уровня 4.1.1.0 (или он устанавливается вместе с набором файлов new.fileset.rte), то то будет установлено обновление wordprocessorB уровня 4.1.1.1 и выше.

3. В следующем примере проиллюстрировано применение условия на дополняющее программное обеспечение. Набор файлов Super.msg.in_IN.Widget уровня 2.1.0.0 является дополняющим по отношению к следующему набору файлов:

   Super.Widget 2.1.0.0
   

   Набор файлов Super.msg.in_IN.Widget не устанавливается по умолчанию в случаях, когда не установлен набор файлов Super.Widget. Однако набор файлов Super.msg.in_IN.Widget можно установить и без набора файлов Super.Widget, если явно указать его в командной строке.

4. Следующий пример иллюстрирует групповые условия. Для установки набора файлов требуется, чтобы был установлен хотя бы один из указанных наборов файлов (могут быть установлены и оба набора). Групповое условие будет выполнено, если в системе установлен набор файлов spreadsheet_1 уровня 1.2.0.0 или выше, набор файлов spreadsheet_2 уровня 1.3.0.0 или выше, либо оба этих набора.

   >0 {
   *prereq spreadsheet_1 1.2.0.0
   *prereq spreadsheet_2 1.3.0.0
   }
   

5. Следующий пример иллюстрирует применение альтернативного формата условий для совместимости с пакетами AIX версий 3.1 и 3.2. Все указанные условия равносильны условию *prereq database 1.2.0.0 и выполняются тогда же, когда выполняется это условие из примера 2.

   *prereq database v=1 r=2
   *prereq database v=1 r=2 o=3
   *prereq database v=1 r=2 o>2
   *prereq database v=1 r=2 m=0 f=0
   

   Примечание: В пояснениях к примерам указано, что все условия выполняются и в тех случаях, когда вместо указанного уровня набора файлов установлен более высокий уровень. Это правило не действует в том случае, если в разделе информации о заменяемом программном обеспечении в файле lpp_name указано иное. Дополнительная информация приведена в разделе Информация о заменяемом программном обеспечении.

Размер и сведения о лицензионном соглашении

В этом разделе файла lpp_name содержится информация о том, сколько дисковой памяти требуется для установки набора файлов, а также сведения о лицензионном соглашении.

Информация о размере

Программа installp перед установкой набора файлов проверяет, достаточно ли свободной памяти в системе, и если требования из этого раздела не выполнены, набор файлов не устанавливается. Информация о размере указывается в следующем формате:

каталог постоянный-объем-памяти[временный-объем-памяти]

Помимо этого, можно задать требования к объему пространства подкачки и дополнительной рабочей памяти, которая потребуется во время установки. Для этого в поле пути к файлу нужно указать опции PAGESPACE и INSTWORK.

Если в поле Каталог указано PAGESPACE, то значение постоянная-память задает объем пространства подкачки (в блоках по 512 байт), требуемый для установки.

Если в поле Каталог указано значение INSTWORK, то значение постоянная-память задает объем памяти (в блоках по 512 байт), необходимый для распаковки управляющих файлов, применяемых во время установки. Эти управляющие файлы должны содержаться в архиве liblpp.a.

Если в поле Каталог указано INSTWORK, то значение временная-память задает размер сжатого файла liblpp.a в блоках по 512 байт.

Ниже приведен пример раздела с информацией о размере:

/usr/bin        30
/lib            40 20
PAGESPACE       10
INSTWORK        10  6

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

Размер обновлений должен быть задан с учетом заменяемых файлов, старые версии которых будут перемещены в каталоги save. Эти файлы сохраняются на случай, если при установке новой версии возникнут ошибки и придется восстанавливать старую версию. Для того чтобы задать требования к объему памяти для сохранения старых файлов, укажите следующие значения:

Для обновлений версии 3.2 применяются следующие каталоги сохранения:

Сведения о лицензионном соглашении

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

Файлы лицензионных соглашений помечаются маркером следующего вида: LAF<%локаль>/, где LAF - это акроним обозначения License Agreement File (Файл лицензионного соглашения), а локаль - идентификатор локали, для которой предназначен данный файл. Если локаль не указана, то предполагается, что файл сохранен в кодировке ASCII и написан на английском языке. Если файл написан на другом языке, то локаль обязательно должна быть указана. В противном случае данное лицензионное соглашение не удастся зарегистрировать.
Оставшаяся часть строки - это путь к файлу лицензии в данном пакете. При каждом изменении лицензии должен меняться и путь к файлу. Лицензии нельзя изменять, поскольку это означало бы изменение условий, регламентирующих использование уже установленных продуктов. Сведения о лицензионном соглашении должны быть указаны хотя бы в одном наборе файлов пакета, при этом упоминаться лицензия может в произвольных наборах файлов пакета. Рекомендуется указывать сведения о лицензионном соглашении только в одном наборе файлов, так как в противном случае в пакете будет содержаться избыточная информация. Примечание: файл лицензионного соглашения должен быть вне списка устанавливаемых файлов и вне реестра набора файлов - это необходимо для того, чтобы он не удалялся при удалении набора файлов. Однако каталоги, в которых хранятся файлы лицензий, должны быть указаны в списке устанавливаемых файлов и в реестре, поскольку без этого невозможно правильно установить права доступа к каталогам.
Второе поле в маркере файла лицензионного соглашения - размер этого файла в блоках по 512 байт, округленный вверх до ближайшего значения, кратного 4096 байтам.

Сведения о лицензионном соглашении задаются с помощью специального маркера, который начинается с символов LAR/ (акроним License Agreement Requirement - Требование лицензионного соглашения). Оставшаяся часть этого значения - путь к конкретной лицензии. Второе поле этого маркера равно нулю, поскольку в данном случае сведения о размере берутся напрямую из файла с лицензионным соглашением.

Локализация: все файлы лицензионного соглашения (на разных языках) должны быть указаны в разделе сведений о размере и лицензионных соглашениях хотя бы у одного набора файлов в пакете. Для каждого файла с лицензионным соглашением должна быть задана локаль.
Записи о лицензионных соглашениях должны указывать шаблон пути к файлам лицензий. Шаблон %L обозначает локаль и позволяет выбрать нужный файл.

В следующем примере продукт IcedTea поставляется с лицензионным соглашением на английском, японском и немецком языках. Для установки набора файлов IcedTea.rte требуется принять лицензионное соглашение, причем оно содержится в этом наборе файлов. Стандартное расположение файла с лицензией для пакета IcedTea - /usr/opt/IcedTea/license/LANG/license.txt. В разделе сведений о размере и лицензии набора файлов IcedTea.rte будут содержаться следующие записи:

LAF%en_US/usr/opt/IcedTea/license/en_US/license.txt 8
LAF%ja_JP/usr/opt/IcedTea/license/ja_JP/license.txt 8
LAF%de_DE/usr/opt/IcedTea/license/de_DE/license.txt 8
LAR/usr/opt/IcedTea/license/%L/license.txt 0

В пакет с набором файлов IcedTea.rte будут включены следующие файлы:

./usr/opt/IcedTea/license/en_US/license.txt
./usr/opt/IcedTea/license/ja_JP/license.txt
./usr/opt/IcedTea/license/de_DE/license.txt

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

Информация о заменяемом программном обеспечении

В этом разделе указываются сведения о том, какие уровни набора файлов могут (или не могут) быть заменены набором файлов с данным уровнем. Это необязательный раздел, и он может относиться только к пакетам базовых уровней в формате 4.1 и к обновлениям в формате 3.2.

В некоторых случаях очередной уровень набора файлов может заменять не все предыдущие уровни. В такой ситуации в файле lpp_name должен быть задан максимальный заменяемый уровень. Команда installp не заменит набор файлов, если его уровень старше уровня, указанного в этом разделе.

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

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

Предположим, что обновление farm.apps.hog 4.1.0.1 заменяет файл /usr/sbin/sellhog. В то же время, обновление farm.apps.hog 4.1.0.3 заменяет файлы /usr/sbin/sellhog и /etc/hog. В свою очередь, обновление farm.apps.hog 4.1.1.2 заменяет файл /usr/bin/raisehog.

Обновление farm.apps.hog 4.1.0.3 заменяет обновление farm.apps.hog 4.1.0.1, так как оно заменяет те же файлы и относится к той же модификации базового набора файлов (farm.apps.hog 4.1.0.0).

Обновление farm.apps.hog 4.1.1.2 не заменяет ни обновление farm.apps.hog 4.1.0.3, ни обновление farm.apps.hog 4.1.0.1, так как оно содержит не все файлы, заменяемые этими обновлениями, и относится к другой модификации базового набора файлов (farm.apps.hog 4.1.1.0). Обновление farm.apps.hog 4.1.1.0 заменяет обновления farm.apps.hog 4.1.0.1 и farm.apps.hog 4.1.0.3.

Информация о заменяемом программном обеспечении для базовых уровней набора файлов

В установочном пакете набора файлов в формате AIX версии 4.1 могут содержаться следующие операторы заменяемого программного обеспечения:

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

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

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

В качестве примера предположим, что набор файлов Year.Full 19.91.0.0 был разделен на несколько отдельных наборов файлов и больше не поставляется. В одном из этих отдельных наборов файлов, например, в Winter 19.94.0.0, должен быть указан оператор совместимости с Year.Full 19.94.0.0. Этот оператор позволяет устанавливать набор файлов Winter 19.94.0.0 вместо набора файлов Year.Full уровня 19.94.0.0 и ниже в тех случаях, когда набор файлов Year.Full требуется для работы каких-либо других наборов файлов.

Информация о заменяемом программном обеспечении для обновлений AIX версии 3.2

Обновление в формате 3.2 может заменять другое обновление того же набора файлов только в том случае, если все файлы и процедуры настройки, содержавшиеся в старом обновлении, содержатся и в новом обновлении, и при этом базовые уровни всех наборов файлов устанавливаемого обновления совпадают с базовыми уровнями обновляемых наборов файлов. Команда installp не принимает решений о возможности замены обновлений в формате 3.2 на основании информации об их уровне и сведений о необходимом программном обеспечении. В связи с этим для каждого обновления в формате 3.2 должны быть явно заданы идентификаторы исправлений всех обновлений, которые могут заменяться данным обновлением. Раздел заменяемого программного обеспечения для обновления в формате 3.2 должен представлять собой список операторов, разделенных символами новой строки. Каждая запись должна содержать идентификатор исправления и имя заменяемого набора файлов.

Обработка информации о заменяемом программном обеспечении

В команде installp предусмотрены следующие возможности для установки наборов файлов и обновлений, заменяющих другие наборы файлов и обновления:

• Если на установочном носителе нет набора файлов или обновления, запрошенного пользователем, то команда installp может установить заменяющий набор файлов или исправление, если найдет его на установочном носителе.

Предположим, что пользователь вызвал команду installp с флагом -g (автоматическая установка необходимого программного обеспечения) для набора файлов farm.apps.hog 4.1.0.2. Если на установочном носителе записан только набор файлов farm.apps.hog 4.1.0.4, команда installp установит farm.apps.hog 4.1.0.4 как заменяющий набор файлов.

• Если в системе и на установочном носителе нет необходимого набора файлов или обновления, то вместо него может использоваться заменяющий набор файлов или обновление.
• Если в запросе на установку обновления указан флаг -g, то будет установлено записанное на носителе обновление максимального возможного уровня.
• Если после проверки требований к установке выяснится, что необходимо записать два уровня обновления, причем один из них будет заменять другой и они оба записаны на установочном носителе, то команда installp установит только обновление более высокого уровня.

Если в команде installp указан флаг -g, то все необходимые обновления (как явно указанные в командной строке, так и добавленные в список установки после проверки требований) будут заменены на заменяющие обновления максимально высокого уровня, найденные на установочном носителе. В связи с этим, если пользователю требуется установить конкретный уровень обновления (не обязательно самый высокий), в команде installp не следует указывать флаг -g.

Если в последнем случае пользователь хочет последовательно установить с носителя два обновления различных уровней, ему потребуется вызвать команду installp для каждого из этих уровней. Обратите внимание на то, что эта операция потеряет всякий смысл, если в командной строке вместе с флагом установки будет указан флаг фиксации (-ac). При фиксации второго обновления первое будет удалено из системы.

Информация об исправлениях

Раздел с информацией об исправлениях не обязателен и допустим только для установочных пакетов с обновлениями. В этом разделе содержится код исправления и описание исправленной ошибки длиной до 60 символов. Код исправления представляет собой уникальный идентификатор данного исправления длиной до 16 символов. Коды исправлений, начинающиеся с символов ix и IX, зарезервированы для разработчиков операционной системы AIX.

Обновлением уровня обслуживания называется обновление, существенно изменяющее функциональные возможности продукта. Примерами обновлений уровня обслуживания могут служить пакеты профилактического обслуживания (PMP) AIX. Идентификатор уровня обслуживания начинается с имени продукта (а не пакета), за которым следует точка (.) и идентификатор уровня обслуживания, например: farm.4.1.1.0.

Библиотечный файл управления установкой - liblpp.a

Файл liblpp.a - это архивный файл AIX, содержащий файлы для управления установкой пакета. Файл liblpp.a можно создать с помощью команды ar. В этом разделе описано большинство стандартных файлов, входящих в архив liblpp.a.

В именах управляющих файлов, упоминаемых в этом разделе, присутствует компонент набор-файлов. Набор-файлов задает имя отдельного набора файлов, устанавливаемого в составе пакета программного обеспечения. Например, файл со списком установки обозначается как набор-файлов.al. Это означает, что список установки для компонента bos.net.tcp.client продукта bos.net хранится в файле bos.net.tcp.client.al.

Имена всех файлов, входящих в архив liblpp.a и не описанных в этой главе, должны удовлетворять следующим условиям:

• Если файл используется при установке конкретного набора файлов, его имя должно начинаться с префикса набор-файлов .
• Если файл нужен для установки нескольких наборов файлов, входящих в один пакет, его имя должно начинаться с префикса lpp..

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

Файлы данных, содержащиеся в файле liblpp.a

./usr/ccs/lib/libc/member.o ./usr/ccs/lib/libc.a

Необязательные исполняемые файлы, содержащиеся в файле liblpp.a

Выполняемые файлы, описанные в этом разделе, вызываются в процессе установки пакета. Если не указано иное, файлы, имена которых заканчиваются символами _i, вызываются при установке, а файлы, имена которых заканчиваются символами _u, - при обновлении продукта. Все файлы, описанные в этом разделе, не обязательны и могут быть как сценариями оболочки, так и выполняемыми объектными модулями. Все программы должны завершаться с кодом возврата 0, кроме случаев, когда при выполнении программы выясняется, что продолжение установки невозможно.

Если какой-либо из этих программ требуется выполнить команду, которая может изменить конфигурацию устройств системы, перед выполнением этой команды данная программа должна проверить значение переменной среды INUCLIENTS. Если переменная INUCLIENTS определена, конфигурацию устройств системы изменять нельзя. В среде сетевой установки (NIM) программа installp используется в различных целях, и в некоторых случаях команда installp не должна выполнять часть обычно выполняемых операций. Переменная INUCLIENTS определяется в среде NIM в тех случаях, когда некоторые операции выполнять не следует.

Если стандартные процедуры не подходят для обработки вашего пакета, вы можете включить в файл liblpp.a дополнительные исполняемые файлы, перечисленные ниже. В этом случае программа installp будет выполнять ваши файлы вместо соответствующих системных файлов. Ваши версии этих файлов должны выполнять все функции стандартных файлов; в противном случае результаты установки будут непредсказуемы. Рекомендуем вам создавать собственные файлы только на основе стандартных, и вообще пользоваться собственными файлами только в крайних случаях.

Для обеспечения совместимости с командой installp ваши программы instal и update должны удовлетворять следующим требованиям:

• Обрабатывать все наборы файлов продукта. Программа может либо выполнять обработку самостоятельно, либо вызывать другие выполняемые файлы.
• Сохранять старые версии заменяемых файлов с помощью команды inusave.
• Восстанавливать все файлы компонента usr с установочного носителя с помощью команды inurest.
• Копировать все необходимые файлы компонента root из каталога /usr/lpp/пакет/inst_root с помощью команды inucp.
• Создавать файл $INUTEMPDIR/status с информацией о результатах обработки всех устанавливаемых и обновляемых наборов файлов. Дополнительная информация об этом файле приведена в разделе Файл результатов установки.
• Выдавать код возврата, соответствующий результатам установки. Если программа instal или update возвращает ненулевой код возврата и при этом не существует файла status, то предполагается, что ни один набор файлов не обработан.

Необязательный исполняемый файл, содержащийся в файле набор-файлов.al

Подробное описание файлов управления установкой

Файл набор-файлов.cfgfiles

В файле набор-файлов.cfgfiles перечислены файлы конфигурации, которые должны быть сохранены для перехода на новую версию набора файлов без потери пользовательских данных. Файл набор-файлов.cfgfiles должен находиться в файле liblpp.a, относящемся к тому же компоненту (usr, root или share), что и файлы с пользовательскими данными.

Файл набор-файлов.cfgfiles содержит список всех файлов, которые требуется сохранить. В каждой строке данного файла должен быть указан абсолютный путь к сохраняемому файлу, пробел и ключевое слово, указывающее способ обработки этого файла. Предусмотрены следующие ключевые слова:

Все дополнительные операции над файлами конфигурации, которые нельзя выполнить стандартными средствами, должны выполняться программой набор-файлов.post_i.

Файлы конфигурации, перечисленные в файле набор-файлов.cfgfiles, сохраняются в том же каталоге сохранения конфигурации, что и сам файл набор-файлов.cfgfiles. Имя каталога сохранения хранится в переменной среды MIGSAVE. Для разных компонентов (usr, share и root) применяются различные каталоги сохранения:

Если группа файлов, которую требуется сохранить, зависит от того, какой уровень набора файлов установлен в системе, то в файле набор-файлов.cfgfiles должны быть перечислены все файлы конфигурации, которые могут нуждаться в замене. Выбор конкретных файлов для сохранения должен осуществляться программой набор-файлов.post_i.

Предположим, что в набор файлов foo.rte входит один файл конфигурации. Этот файл относится к компоненту root, и поэтому он указан в файле foo.rte.cfgfiles для компонента root:

/etc/foo_user   user_merge

При переходе от старого набора файлов (foo.obj) к набору файлов foo.rte вы не можете сохранить этот файл, потому что его формат был изменен. В то же время, этот файл может сохраняться при установке новых уровней foo.rte. Поэтому вам требуется написать сценарий foo.rte.post_i, который будет действовать с учетом того, какой набор файлов был установлен в системе ранее. В этом случае изменения, внесенные пользователем в файл /etc/foo_user, не будут потеряны при обновлении.

Сценарий foo.bar.post_i может выглядеть следующим образом:

#! /bin/ksh
grep -q foo.rte $INSTALLED_LIST
if [$? = 0]
then
  mv $MIGSAVE/etc/foo_user/ /etc/foo_user
fi

Команда installp определяет и экспортирует переменную среды $INSTALLED_LIST. Описание файла конфигурации набор-файлов.installed_list приведен в разделе Файлы управления установкой для продуктов с измененной структурой Файлы управления установкой для продуктов с измененной структурой). В переменной $MIGSAVE хранится имя каталога, в котором сохраняются файлы конфигурации компонента root.

Если команде installp не удается найти какой-либо из файлов, указанных в файле набор-файлов.cfgfiles, то она не выдает никаких сообщений. Кроме того, команда installp не выдает сообщений о файлах, не найденных во время выполнения сценария набор-файлов.post_i (этот сценарий восстанавливает сохраненные файлы конфигурации после установки новой версии набора файлов). Если вы хотите, чтобы пользователь получал какие-либо сообщения в таких ситуациях, эти сообщения должны выдаваться вашими сценариями.

Рассмотрим пример применения файла набор-файлов. cfgfiles. Допустим, в наборе файлов Product_X.option1 предусмотрено три файла конфигурации, относящихся к компоненту root. Файл Product_X.option1.cfgfiles включен в ту часть файла liblpp.a, которая относится к компоненту root. Содержимое этого файла приведено ниже:

./etc/cfg_leaf    preserve
./etc/cfg_pudding user_merge
./etc/cfg_newton  preserve

Файл набор-файлов.fixdata

Сведения из этого файла добавляются в базу данных исправлений. С помощью этой базы данных команда instfix определяет, какие исправления установлены в системе. Если в пакете есть файл набор-файлов.fixdata, содержимое этого файла заносится в базу данных исправлений при установке пакета.

Для каждого исправления должен быть отведен отдельный раздел файла набор-файлов.fixdata. Разделы файла набор-файловfixdata задаются в следующем формате:

fix:
    name = ключевое-слово
    abstract = описание
    type = {f | p}
    filesets = имя-набора-файлов уровень-набора-файлов
    [имя-набора-файлов уровень-набора-файлов ...]
    [symptom = [симптом]]

Длина значения ключевое-слово не должна превышать 16 символов. В поле abstract указывается краткое описание исправления длиной не более 60 символов. В поле type должно быть указано значение f (исправление) или p (обновление уровня обслуживания). В поле filesets должен содержаться список имен и уровней наборов файлов. Значение уровень-набора-файлов указывает начальный уровень набора файлов, в котором полностью или частично исправлена ошибка. В необязательном поле symptom можно указать описание ошибки, устраненной данным исправлением. Длина поля symptom не ограничена.

Ниже приведен пример раздела файла набор-файлов.fixdata для ошибки MS21235. Исправление этой ошибки реализовано в двух наборах файлов.

fix:
    name = MS21235
    abstract = 82-гигабайтный дисковод не работает на Марсе
    type = f
    filesets =  devices.mca.8d77.rte 12.3.6.13
            devices.mca.8efc.rte 12.1.0.2
    symptom = 82-гигабайтные субатомные дискеты не работают в марсианской атмосфере.

Файл набор-файлов.inventory

Для каждого компонента, в котором есть новые или измененные файлы, должен поставляться отдельный файл набор-файлов.inventory. Если в установочном пакете есть компонент root, но в этом компоненте нет ни одного нового и измененного файла, то файл набор-файла.inventory для компонента root не требуется.

Примечание: В файле набор-файлов.inventory можно указывать только информацию о файлах, размер которых не превышает 2 Гб. Если в вашем установочном пакете есть файлы размером более 2 Гб, укажите их файле набор-файлов.al, но не задавайте их в файле набор-файлов.inventory. Команда sysck в настоящее время не поддерживает файлы размером более 2 Гб; кроме того, во многих системах файловая система /usr по умолчанию не поддерживает файлы размером более 2 Гб.

Файл inventory - это текстовый файл в стандартном формате файла настройки. Имена разделов этого файла представляют собой полные пути к устанавливаемым файлам. Имя раздела должно заканчиваться двоеточием (:), за которым следует символ новой строки. После имени раздела могут быть указаны атрибуты в формате атрибут=значение. Каждый атрибут должен быть указан в отдельной строке. Допустимы следующие атрибуты:

Примечание: Если указанные символьные и жесткие связи не существуют, то команда sysck создаст их во время установки. Символьные связи компонента root должны быть указаны в файле набор-файлов.inventory, относящемся к компоненту root.

Файлы управления установкой для продуктов с измененной структурой

Файл набор-файлов.installed_list

Для того чтобы узнать, установлен ли набор файлов набор-файлов или какие-либо из наборов файлов, перечисленных в файле набор-файлов.namelist (если он есть), команда installp просматривает базу данных программного обеспечения. Если какие-либо компоненты уже установлены, то в файл набор-файлов.installed_list заносится список имен и уровней установленных наборов файлов.

Если файла набор-файлов.installed_list нет, он создается перед вызовом программ rminstal и instal. Файл набор-файлов.installed_list может находиться в рабочем каталоге пакета, в каталоге рабочий-каталог-пакета или в одном из следующих каталогов:

В файле набор-файлов.installed_list перечислены все установленные наборы файлов. В каждой записи файла указаны имя и уровень набора файлов.

Например, предположим, что при установке набора файлов storm.rain1.2.0.0 команда installp обнаружила, что в системе уже установлен набор файлов storm.rain1.1.0.0. В этом случае команда installp создает файл рабочий-каталог-пакета/storm.rain.installed_list со следующей информацией:

storm.rain 1.1.0.0

Другой пример: допустим, в набор файлов Baytown.com входит файл Baytown.com.namelist следующего содержания:

Pelly.obj
GooseCreek.rte
CedarBayou.stream 

При установке набора файлов Baytown.com2.3.0.0 команда installp обнаружила, что в системе Pelly.obj 1.2.3.0 уже установлен набор файлов CedarBayou.stream4.1.3.2. В этом случае команда installp создаст файл рабочий-каталог-пакета/Baytown.com.installed_list со следующей информацией:

Pelly.obj 1.2.3.0
CedarBayou.stream 4.1.3.2

Файл набор-файлов.namelist

Файл набор-файлов.namelist содержится в разделе файла liblpp.a, относящемся к соответствующему компоненту (usr, root или share). Файл набор-файлов.namelist может поставляться только с установочными пакетами базового уровня; его нельзя поставлять с обновлениями.

В начале установки команда installp просматривает реестр программного обеспечения (SWVPD) и пытается определить, установлены ли в системе какие-либо из наборов файлов, перечисленных в файле набор-файлов.namelist. Если найден хотя бы один набор файлов, команда installp создает файл набор-файлов.installed_list и записывает в него имена и уровни найденных наборов файлов.

Рассмотрим пример применения файла набор-файлов.namelist. Пусть набор файлов small.business заменяет поставлявшийся ранее набор файлов family.business. В установочном пакете small.business содержится файл small.business.namelist, хранящийся в файле liblpp.a в разделе компонента usr. В данном случае в файле small.business.namelist должна быть указана следующая информация:

family.business

В качестве более сложного примера применения файла набор-файлов.namelist, рассмотрим набор файлов, состоящий из двух частей: клиента и сервера. Наборы файлов LawPractice.client и LawPractice.server поставляются вместо устаревшего набора файлов lawoffice.mgr. Помимо этого, в набор файлов LawPractice.server входит несколько файлов из устаревшего набора файлов BusinessOffice.mgr. В файле LawPractice.client.namelist, который находится в файле liblpp.a установочного пакета LawPractice, должна содержаться следующая информация:

lawoffice.mgr

В файле LawPractice.server.namelist из файла liblpp.a пакета LawPractice должна содержаться следующая информация:

lawoffice.mgr
BusinessOffice.mgr

Если файл набор-файлов.namelist содержит только одну запись, а новый набор файлов не полностью заменяет набор файлов, указанный в файле набор-файлов.namelist, то в файл liblpp.a должен быть включен набор файлов набор-файлов.rm_inv. Команда installp определяет, какие наборы файлов полностью заменяются устанавливаемым набором файлов, по содержимому файлов набор-файлов.namelist и набор-файлов.rm_inv. Если файл набор-файлов.namelist состоит из одной строки, и при этом нет файла набор-файлов.rm_inv, то предполагается, что новый набор файлов напрямую и полностью заменяет указанный старый набор файлов. В этом случае старый набор файлов полностью удаляется из системы при установке нового (заменяющего) набора файлов, даже если в старом наборе файлов были файлы, которых нет в новом наборе файлов.

В предыдущих примерах набор файлов small.business полностью заменял набор файлов family.business, поэтому для него не требовалось создавать файл small.business.rm_inv. Однако набор файлов LawPractice.client не полностью заменял набор файлов lawoffice.mgr, поэтому для него обязательно должен быть создан файл LawPractice.client.rm_inv, даже если он будет пустым.

Файл набор-файлов.rm_inv

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

Если вам требуется просто переименовать набор файлов, то файл набор-файлов.rm_inv создавать не нужно. Файл набор-файлов.rm_inv нужен только в случаях, когда новый набор файлов представляет собой подмножество файлов одного или нескольких устаревших наборов файлов. Если файл набор-файлов.namelist есть в установочном пакете, и в нем указано несколько наборов файлов, то файл набор-файлов.rm_inv обязательно потребуется для удаления старых версий файлов из системы.

Файл набор-файлов.rm_inv - это текстовый файл в стандартном формате файла настройки. Имена разделов этого файла представляют собой полные пути к файлам или каталогам, которые должны быть удалены из системы (в случае, если они установлены). Имя раздела должно заканчиваться двоеточием (:), за которым следует символ новой строки. После имени раздела могут быть указаны атрибуты в формате атрибут=значение. Атрибуты применяются для определения жестких и символьных связей, которые также требуется удалить. Каждый атрибут должен быть указан в отдельной строке. Допустимы следующие атрибуты:

Например, набор файлов U.S.S.R 19.91.0.0 содержал следующие файлы в каталоге /usr/lib: moscow, leningrad, kiev, odessa и petrograd (символьная связь с файлом leningrad). Разработчики решили разделить набор файлов U.S.S.R19.91.0.0 на два набора файлов: Ukraine.lib 19.94.0.0 и Russia.lib 19.94.0.0. Набор файлов Ukraine.lib состоит из файлов kiev и odessa. Набор файлов Russia.lib состоит из файла moscow. Файл leningrad устарел и заменен файлом st.petersburg в наборе файлов Russia.lib.

Файл Ukraine.lib.rm_inv необходим постольку, поскольку набор файлов Ukraine.lib не полностью заменяет набор файлов U.S.S.R. Файл Ukraine.lib.rm_inv должен быть пустым, так как при установке набора файлов Ukraine.lib не нужно удалять файлы, относящиеся к устаревшему набору файлов U.S.S.R.

По этим же причинам должен поставляться файл Russia.lib.rm_inv - поскольку набор файлов Russia.lib не полностью заменяет набор файлов U.S.S.R. Поскольку файл leningrad заменен другим файлом в наборе Russia.lib.rm_inv, его следует указать в файле Russia.lib.rm_inv. В этом случае файл leningrad будет автоматически удален при установке набора файлов Russia.lib. Файл Russia.lib.rm_inv должен содержать следующую информацию:

/usr/lib/leningrad:
     symlinks = /usr/lib/petrograd

Установочные файлы для дополнительных дисковых подсистем

Если для поставляемого устройства, подключаемого к SCSI или системной шине, требуются собственные драйвер и процедуры настройки, то изготовитель этого устройства должен поставлять специальные установочные файлы. Эти файлы должны быть записаны в формате backup на дискете, входящей в комплект поставки устройства, и им должны быть присвоены имена ./signature и ./startup. В файле signature должна содержаться строка target. Файл startup должен представлять собой сценарий, который разархивирует нужные файлы с дискеты с помощью команды restore, а затем выполняет все действия по настройке и подготовке устройства к работе.

Формат дистрибутивных носителей

Установочные пакеты программных продуктов могут поставляться на следующих видах носителей:

• Магнитные ленты
• Компакт-диски
• Дискеты

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

Магнитные ленты

Если вы хотите записать установочные образы нескольких продуктов на одну ленту или один набор лент, то для каждой магнитной ленты должны быть выполнены следующие условия:

• Файл 1 должен быть пустым. (Он может быть непустым только у загрузочных магнитных лент.)
• Файл 2 должен быть пустым. (Он может быть непустым только у загрузочных магнитных лент.)
• Файл 3 должен представлять собой таблицу содержимого с информацией о том, какие установочные образы записаны на данном наборе магнитных лент. Соответственно, на каждой магнитной ленте набора должна быть записана одна и та же полная таблица содержимого, отличающаяся только порядковыми номерами лент в наборе. Дополнительная информация приведена в разделе Файл с таблицей содержимого.
• Файлы с 4 по (N+3) содержат установочные образы продуктов 1 - N в формате backup.
• Каждый установочный образ должен целиком располагаться на одной ленте.
• После каждого файла на ленте должна быть записана метка конца файла.

Компакт-диски

Компакт-диски с установочными образами нескольких продуктов должны соответствовать протоколу RRGP (Rock Ridge Group Protocol). Установочные пакеты должны находиться в каталоге /usr/sys/inst.images, который должен содержать следующие данные:

• Установочные образы в формате backup.
• Таблицу содержимого в файле .toc с информацией обо всех установочных образах, записанных в данном каталоге. Дополнительная информация по этому вопросу приведена в разделе Файл с таблицей содержимого.

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

Многотомный установочный носитель из компакт-дисков должен удовлетворять следующим требованиям:

• На каждом диске должен существовать каталог /usr/sys/mvCD со следующей информацией:
  1. Файл содержимого (.toc) с информацией обо всех установочных образах, записанных на всех томах. На всех томах в каталоге /usr/sys/mvCD должен быть записан один и тот же файл .toc.
  2. Текстовый файл с именем volume_id, в котором в первой строке указан номер компакт-диска в наборе.
  3. Символьная связь с именем vol%n, где n - десятичный номер диска в наборе. Эта символьная связь должна указывать на каталог продуктов, записанных на данном компакт-диске. Обычно эта связь указывает на ../inst.images.
• Файл с таблицей содержимого (.toc) в каталоге /usr/sys/mvCD должен соответствовать обычным требованиям к этому файлу. Единственное отличие файла .toc для многотомного носителя заключается в том, что расположение каждого установочного образа должно начинаться с каталога vol% n, где n - номер тома, на котором записан этот установочный образ.

Пример:

Набор файлов A записан в файле A.bff на томе 1. Набор файлов B записан в файле B.bff на томе 2. В таблице содержимого в каталоге /usr/sys/mvCD в обоих томах расположение этих наборов файлов указано, соответственно, как vol%1/A.bff и vol%2.bff. В таблице содержимого в каталоге /usr/sys/inst.images тома 1 расположение А указано как A.bff. В таблице содержимого тома 2 в каталоге /usr/sys/inst.images расположение В указано как B.bff.

Примечание: Многотомные носители на основе компакт-дисков поддерживаются только начиная с версии AIX 4.3. В предыдущих версиях AIX каждый том обрабатывается независимо от других. В связи с этим, рекомендуем вам создавать многотомные носители таким образом, чтобы при необходимости их было можно обрабатывать отдельно друг от друга (учитывая возможность возникновения ситуаций, когда компакт-диск нельзя размонтировать и поэтому остальные тома становятся недоступны).

Дискеты

Если вы хотите создать многотомный установочный носитель из дискет, на дискетах должны быть записаны следующие файлы:

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

При записи файлов на дискеты должны быть выполнены следующие правила:

• Данные должны записываться в виде потока; в блоке 0 каждой дискеты должен быть записан ИД тома. Данные, записанные в блоке 1 очередного тома, рассматриваются как логическое продолжение данных, записанных в последнем блоке предыдущего тома.
• Начало каждого файла должно приходиться на начало 512-байтового блока.
• Первым файлом набора дискет должна быть таблица содержимого. Последний сектор, занимаемый таблице содержимого, должен быть дополнен нулевыми байтами (x'00'). В конце таблицы содержимого должен быть хотя бы один нулевой байт - признак границы. Если таблица содержимого занимает целое число секторов, следующий сектор должен быть целиком заполнен нулевыми байтами.
• После таблицы содержимого должны быть последовательно записаны установочные образы всех продуктов. Последний сектор каждого образа должен дополняться нулевыми байтами. Если установочный образ занимает целое число секторов, то дополнительный нулевой сектор не требуется.
• В блоке 0 каждой дискеты должен быть записан ИД тома. ИД тома записывается в отдельном секторе в следующем формате:
  

  Байты 0:3	Сигнатура. Установочным носителям выделена сигнатура 3609823513=x'D7298918'.
  Байты 4:15	Дата и время. Это значение должно быть указано в формате месяц-день-час-минута-секунда-год. В поле час должно быть указано значение от 00 до 23. Все поля даты и времени состоят из 2 цифр. Поэтому для обозначения марта в поле месяц должно быть указано 03, а не 3, а для обозначения 1994 года в поле год должно быть указано 94, а не 1994.
  Байты 16:19	Двоичный номер дискеты в данном наборе. Первой дискете присваивается номер x'00000001'.
  Байты 20:511	Двоичные нули.

Файл с таблицей содержимого

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

Примечание: Поля 4 и 5 повторяются для каждого установочного образа, записанного на носителе.

Формат даты и времени

Дата и время указываются в следующем формате:

месяц-день-час-минута-секунда-год

В поле час должно быть указано значение от 00 до 23. Все поля даты и времени состоят из 2 цифр. Поэтому для обозначения марта в поле месяц должно быть указано 03, а не 3, а для обозначения 1994 года в поле год должно быть указано 94, а не 1994.

Формат поля расположения

Расположение установочного образа указывается в формате ттт:ббббб:ррррррр:

Магнитная лента

ттт

- номер тома магнитной ленты.

ббббб

- номер файла на магнитной ленте.

рррррррр

- размер файла в байтах.

Дискета

ттт

номер тома дискеты.

ббббб

номер блока дискеты, с которого начинается файл.

рррррррр

- размер файла в байтах (с учетом двоичных нулей, дополняющих файл до целого числа блоков).

Алгоритм работы команды installp

Команда installp может выполнять следующие основные операции:

Разработчик может предоставить собственные сценарии установки, аннулирования и удаления своего продукта.

Повторная установка набора файлов поверх того же уровня не равносильна удалению этого набора файлов с последующей установкой. Сценарий повторной установки (см. /usr/lib/instl/rminstal) удаляет из системы файлы текущей установленной версии, но не выполняет сценарии unconfig и unpre*. В связи с этим, создаваемые вами сценарии не должны исходить из предположения о том, что был выполнен сценарий unconfig. При принятии решений относительно того, была ли удалена информация о конфигурации, сценарий .config должен предварительно проверять среду.

Предположим, что сценарий настройки набора файлов ras.berry.rte добавляет строку в файл crontab пользователя root. Если вы переустановите набор файлов ras.berry.rte, то в файле crontab окажется две записи, поскольку при повторной установке не был выполнен сценарий unconfig (который должен удалять строку из файла crontab). Сценарий настройки в подобной ситуации должен сначала удалять существующую запись, а затем добавлять собственную.

Операция установки

В этом разделе описаны действия, выполняемые командой installp при установке базового уровня или обновления набора файлов.

1. Восстановить информационный файл lpp_name для указанного пакета с заданного устройства.
2. Убедиться, что все запрошенные наборы файлов записаны на установочном носителе.
3. Убедиться, что уровень запрошенных наборов файлов допускает установку этих наборов в системе.
4. Восстановить управляющие файлы из библиотеки liblpp.a в каталог пакета (/usr/lpp/имя-пакета для пакетов usr и usr/root или /usr/share/lpp/имя-пакета для пакетов share. Управляющие файлы для компонента root пакета usr/root находятся в файле /usr/lpp/имя-пакета/inst_root/liblpp.a).
5. Проверить требования к объему свободной дисковой памяти.
6. Проверить, что все необходимое программное обеспечение (наборы файлов, определенный уровень которых должен быть установлен в системе перед началом установки данных наборов файлов) уже установлено или выбрано для установки.
7. Если вы работаете с установочным пакетом (а не с пакетом обновления), то определить, нужно ли принять какие-либо лицензионные соглашения для продолжения установки.
8. Если устанавливается базовый уровень набора файлов, то просмотреть реестр программного обеспечения (SWVPD) и проверить, установлен ли в системе какой-нибудь уровень этого набора файлов или какие-либо наборы файлов из перечисленных в файле набор-файлов.namelist. Если набор-файлов уже установлен, то записать имя и уровень установленного набора файла в файл рабочий-каталог/набор-файлов.installed_list. Если набор-файлов не установлен, но установлены какие-либо наборы файлов, перечисленные в файле набор-файлов.namelist, то их имена и уровни сохраняются в файле рабочий-каталог/набор-файлов.installed_list. Рабочий-каталог обычно совпадает с каталогом, в котором устанавливается весь пакет за исключением компонентов root, которые устанавливаются в каталог /lpp/имя-пакета.
9. Если устанавливается базовый уровень набора файлов, то вызвать сценарий /usr/lib/instl/rminstal для каждого из устанавливаемых наборов файлов (если не указано иное, то к этому моменту существующие файлы должны быть уже восстановлены из библиотеки управляющих файлов liblpp.a):
   1. Если файл набор-файлов.pre_rm существует, то вызвать набор-файлов.pre_rm для подготовки к удалению текущего уровня набора файлов.
   2. Если существует файл рабочий-каталог/набор-файлов.installed_list, то переместить существующие файлы, перечисленные в файле набор-файлов.cfgfiles, в каталог сохранения (путь к каталогу указан в переменной среды MIGSAVE).
   3. Если в системе уже установлен какой-либо уровень набора файлов, то удалить его файлы из системы, а информацию об этом наборе файлов, за исключением хронологии, - из SWVPD.
      

      Иначе

      Если существует файл рабочий-каталог/набор-файлов.installed_list, то:

      Если существует файл набор-файлов.rm_inv или в файле набор-файлов.namelist указано несколько наборов файлов, или в файле набор-файлов.namelist указан только набор файлов bos.obj, то:

      Удалить из системы файлы, перечисленные в файле набор-файлов.rm_inv, а из SWVPD удалить информацию об этих файлах.

      Удалить из системы файлы, перечисленные в файле набор-файлов.inventory, а из SWVPD удалить информацию о них.

      Удалить из SWVPD информацию обо всех наборах файлов, перечисленных в файле набор-файлов.namelist.

      
      

      Иначе

      Если существует файл рабочий-каталог/набор-файлов.installed_list и в нем указан ровно один набор файлов, и при этом существует файл набор-файлов.namelist и в нем также указан ровно один набор файлов, то:

      Удалить файлы этого набора и информацию SWVPD (кроме хронологической информации).

   4. Для каждого компонента пакета (либо только для usr, либо только для share, либо для usr, а затем для root)
      1. Присвоить нужные значения переменным среды INUTREE (U для usr, M для root и S для share ) и INUTEMPDIR (имя ранее созданного временного рабочего каталога).
      2. Если устанавливается базовый уровень набора файлов:
         

         Если в каталоге пакета существует управляющая программа instal (ее создавать не рекомендуется):

         Выполнить ./instal.

         Иначе

         Выполнить стандартный сценарий /usr/lib/instl/instal.

         в противном случае /* если устанавливается обновление */

         Присвоить значение переменной среды INUSAVEDIR.

         Если в каталоге пакета существует управляющая программа update (ее создавать не рекомендуется):

         Выполнить ./update.

         Иначе

         Выполнить стандартный сценарий /usr/lib/instl/update.

      3. Если сценарий instal или update создал файл status, то:
         

         Просмотреть результаты установки каждого набора файлов в файле status.

         Иначе

         Считать, что не удалось обработать ни один набор файлов.

      4. Если набор файлов полностью установлен:
         

         Обновить реестр программного обеспечения (SWVPD).

         Зарегистрировать лицензионное соглашение, если оно существует.

         Иначе

         Выполнить очистку, запустив стандартный сценарий /usr/lib/instl/cleanup (рекомендуемый способ) или сценарий lpp.cleanup из каталога пакета.

Алгоритм работы стандартного сценария установки и обновления

Команда installp передает в качестве первого параметра сценария установки instal или update имя установочного устройства. Второй параметр - полный путь к файлу со списком устанавливаемых или обновляемых наборов файлов. Ниже этот параметр обозначается $FILESETLIST. Стандартные сценарии instal и update отличаются друг от друга. Сценарии вызываются из каталога, в котором устанавливается пакет. В каталоге /tmp создается временный каталог INUTEMPDIR для хранения рабочих файлов. Подробная информация об этих файлах приведена в разделе Файлы управления установкой (Подробное описание файлов управления установкой).

Стандартные сценарии instal и update выполняют следующие действия:

1. Выполнить следующие действия для каждого набора файлов из $FILESETLIST:
   1. 
      

      Если устанавливается обновление:

      Выполнить сценарий набор-файлов.pre_u, если он существует.

      Иначе

      Выполнить файл набор-файлов.pre_i, если он существует.

   2. Создать список файлов, которые требуется скопировать из установочного пакета, путем объединения файла набор-файлов.al с новым файлом INUTEMPDIR/master.al.
   3. Если устанавливается обновление, существуют файлы, которые нужно сохранить, и существует файл lpp.acf (файл управления архивом), то:

      Сохранить обновляемые элементы архива библиотек.
      

   4. Если предыдущая операция выполнена успешно, то добавить текущий набор файлов в список устанавливаемых наборов файлов из файла $FILESETLIST.new.
2. Если устанавливается обновление с опцией сохранения файлов, то вызвать сценарий inusave для сохранения текущих версий файлов.
3. Если в данный момент обрабатывается компонент root,
   

   Скопировать файлы из списка установки в каталог компонента root с помощью команды inucp.

   Иначе

   Восстановить файлы компонента usr или share из списка установки с помощью команды inurest.

4. Для всех наборов файлов, перечисленных в файле $FILESETLIST.new, выполнить следующие действия (имена наборов файлов, при обработке которых возникли ошибки, заносятся в файл status и их обработка прекращается):
   1. Проверить, не указан ли в файле набор-файлов .namelist тот же или более высокий уровень устанавливаемого набора файлов. Если это так, то экспортировать переменные среды INSTALLED_LIST и MIGSAVE (такая ситуация называется миграцией).
   2. Если устанавливается обновление, то выполнить следующие действия:
      

      Выполнить файл набор-файлов.post_u, если он существует.

      Иначе

      Выполнить файл набор-файлов.post_i, если он существует.

      Если существует файл набор-файлов.cfgfiles, вызвать сценарий /usr/lib/instl/migrate_cfg для обработки файлов конфигурации.

   3. Добавить информацию из файла набор-файлов.inventory в реестр программного обеспечения (SWVPD) с помощью команды sysck.
   4. Если существует файл Fileset.tcb, и в базе данных ODM /usr/lib/objrepos/PdAt задан атрибут tcb_enabled, то добавить в систему информацию из защищенной компьютерной базы с помощью команды tcbck.
   5. Если существует файл набор-файлов.err, то добавить шаблоны ошибок с помощью команды errupdate.
   6. Если существует файл набор-файлов.trc, то добавить шаблоны форматирования отчетов трассировки с помощью команды trcupdate.
   7. Если устанавливается обновление или существует файл рабочий-каталог/набор-файлов.installed_list, то вызвать все сценарии вида набор-файлов.odmdel и набор-файлов.*.odmdel для удаления ненужной информации из базы данных ODM.
   8. Вызвать команду odmadd для всех файлов набор-файлов.odmadd и набор-файлов.*.odmadd для добавления информации в базу данных ODM.
   9. Если выполняется операция аннулирования,
      

      Выполнить сценарий набор-файлов.config_u, если он существует.

      Иначе

      Выполнить сценарий набор-файлов.config, если он существует.

   10. Указать в файле status, что текущий набор файлов успешно обработан.
5. Создать связи с управляющими файлами, необходимыми для удаления набора файлов, в каталоге deinstl пакета. Это могут быть следующие файлы:

   lpp.deinstal, набор-файлов.al, набор-файлов.inventory, набор-файлов.pre_d, набор-файлов.unpre_i, набор-файлов.unpre_u, набор-файлов.unpost_i, набор-файлов.unpost_u, набор-файлов.unodmadd, набор-файлов.unconfig, набор-файлов.unconfig_u, $SAVEDIR/набор-файлов.*.rodmadd и SAVEDIR/Fileset. *.unodmadd

Алгоритмы работы стандартных сценариев аннулирования и очистки

В этом разделе описаны шаги, выполняемые командой installp при аннулировании обновлений и при очистке после неудачной установки наборов файлов. Стандартные сценарии cleanup и reject расположены в каталоге /usr/lib/instl и фактически представляют собой одну и ту же программу. Алгоритм работы этой программы незначительно отличается в случаях, когда она вызывается как reject и как cleanup. Если набор файлов состоит из компонентов usr и root, то компоненты root обрабатываются до компонентов usr.

1. Если выполняется операция аннулирования, то убедиться, что одновременно аннулируются все зависимые обновления.
2. Для каждого компонента пакета (usr, root и share) выполнить следующие действия:
   1. Присвоить нужные значения переменным среды INUTREE (U для usr, M для root и S для share) и INUTEMPDIR.
   2. Если в текущем каталоге (INULIBDIR) существует управляющий файл reject:
      

      Вызвать ./lpp.reject

      Иначе

      Выполнить стандартный сценарий /usr/lib/instl/reject

3. Обновить реестр программного обеспечения (SWVPD).

Команда installp передает сценарию reject в качестве первого параметра неопределенное значение, а в качестве второго - полное имя файла со списком аннулируемых наборов файлов (ниже этот файл обозначался как $FILESETLIST).

В сценариях cleanup и reject задействован ряд дополнительных файлов. Подробная информация о них приведена в разделе Подробное описание файлов управления установкой.

Стандартные сценарии cleanup и reject выполняют следующие действия:

1. Выполнить следующие действия для каждого набора файлов из $FILESETLIST:
   1. Если вызван сценарий cleanup, определить по содержимому файла имя-пакета.s, на каком шаге была прервана установка, и перейти к соответствующему шагу. Сценарий cleanup начнет работу только с того шага, на котором произошла ошибка при установке. Например, если ошибка произошла при выполнении сценария набор-файлов.post_i, то очистка начнется с шага (i), поскольку предыдущие шаги выполнять не требуется.
   2. Аннулировать результаты настройки, выполненной во время установки:

      Если выполняется операция аннулирования,
      

      Вызвать сценарий набор-файлов.unconfig_u, если он существует

      Иначе

      Вызвать сценарий набор-файлов.unconfig, если он существует.

   3. Выполнить сценарии вида набор-файлов.*.unodmadd и набор-файлов.unodmadd для удаления записей ODM, добавленных во время установки.
   4. Выполнить сценарии вида набор-файлов .*.rodmadd и набор-файлов.rodmadd, если они существуют, для восстановления записей ODM, удаленных во время установки.
   5. Если существует файл набор-файлов.undo.trc, то выполнить сценарий trcupdate, который удаляет все изменения, внесенные в шаблоны отчетов трассировки при установке набора файлов.
   6. Если существует файл набор-файлов.undo.err, то вызвать сценарий errupdate, который удаляет все изменения, внесенные в шаблоны ошибок во время установки.
   7. Если существует файл набор-файлов.tcb, и в базе данных ODM /usr/lib/objrepos/PdAt задан атрибут tcb_enabled, то удалить из системы информацию из защищенной компьютерной базы с помощью команды tcbck.
   8. Если существует файл набор-файлов.inventory, то выполнить сценарий sysck, который удаляет изменения, внесенные в базу данных программного обеспечения.
   9. Аннулировать результаты операций настройки, выполненных после установки набора файлов:

      Если выполняется операция аннулирования обновления, то:
      

      Вызвать сценарий набор-файлов.unpost_u, если он существует

      Иначе

      Вызвать сценарий набор-файлов.unpost_i, если он существует.

   10. Создать список установки (файл master.al) на основе файлов набор-файла.al.
   11. Добавить набор-файлов в файл $FILESETLIST.new.
2. Если существует файл $INUTEMPDIR/master.al, то выполнить следующие действия:
   1. Перейти в каталог / (root).
   2. Удалить все файлы, указанные в файле master.al.
3. Прочитать файл $FILESETLIST.new и выполнить следующие действия:
   1. С помощью программы inurecv восстановить все сохраненные файлы.
   2. Если выполняется операция аннулирования обновления, то:
      

      Вызвать сценарий набор-файлов.unpre_u, если он существует.

      Иначе

      Вызвать сценарий набор-файлов.unpre_i, если он существует.

   3. Удалить файлы управления установкой.
4. Удалить файл состояния имя-пакета.s.

Алгоритм удаления программного обеспечения

В этом разделе описаны действия, выполняемые командой installp при удалении набора файлов. Если набор файлов состоит из компонентов usr и root, то компоненты root обрабатываются до компонентов usr.

1. Убедиться, что одновременно удаляются все зависимые наборы файлов.
2. Для каждого компонента пакета ( usr, root и share) выполнить следующие действия:
   1. Присвоить нужные значения переменным среды INUTREE (U для usr, M для root и S для share) и INUTEMPDIR (рабочий каталог installp в файловой системе /tmp).
   2. Перейти в каталог INULIBDIR.
   3. Если в текущем каталоге существует файл deinstal:
      

      Вызвать ./lpp.deinstal

      Иначе

      Вызвать стандартный сценарий /usr/lib/instl/deinstal.

3. Удалить файлы, относящиеся к данному набору файлов.
4. Удалить всю информацию о наборе файлов, кроме информации хронологии, из реестра программного обеспечения (SWVPD).
5. Отменить регистрацию лицензионного соглашения на применение набора файлов.

Команда installp передает сценарию deinstal в качестве первого параметра полное имя файла со списком удаляемых наборов файлов. Этот файл в дальнейшем будет обозначаться $FILESETLIST.

Сценарий deinstal выполняет следующие действия:

1. Выполнить следующие действия для каждого набора файлов из $FILESETLIST:
2. Если существует файл набор-файлов.unconfig_d:

   Выполнить сценарий набор-файлов .unconfig_d, который аннулирует все изменения конфигурации, изменения в базе данных ODM, изменения в шаблонах ошибок и информации трассировки, а также результаты работы сценариев установки обновлений и базового уровня набора файлов.

3. Если файл набор-файлов.unconfig_d не существует:
   1. Для каждого установленного обновления данного набора файлов выполнить следующие действия:
      

      Аннулировать результаты настройки с помощью сценария набор-файлов.unconfig_u.

      Удалить записи ODM, добавленные при установке обновления, с помощью сценариев набор-файлов.*.unodmadd и набор-файлов.unodmadd.

      Добавить в базу данных ODM записи, удаленные при установке обновления, с помощью сценариев набор-файлов.*.rodmadd и набор-файлов.rodmadd.

      Если существует файл набор-файлов.undo.err, то выполнить сценарий errupdate, который аннулирует все изменения в шаблонах ошибок.

      Если существует файл набор-файлов.undo.trc, то выполнить сценарий trcupdate, который аннулирует изменения в шаблонах отчетов трассировки.

      Выполнить сценарий набор-файлов.unpost_u, который аннулирует результаты настройки, выполненной после установки обновления.

   2. Для базового уровня набора файлов выполнить следующие действия:
      

      Выполнить сценарии вида набор-файлов .*.unodmadd и набор-файлов.unodmadd для удаления записей ODM, добавленных во время установки.

      Добавить в базу данных ODM записи, удаленные при установке набора файлов, с помощью сценариев набор-файлов.*.rodmadd и набор-файлов.rodmadd.

      Если существует файл набор-файлов.undo.err, то выполнить сценарий errupdate, который аннулирует все изменения в шаблонах ошибок.

      Если существует файл набор-файлов.undo.trc, то выполнить сценарий trcupdate, который аннулирует изменения в шаблонах отчетов трассировки.

      Выполнить сценарий набор-файлов.unconfig_i, чтобы аннулировать результаты настройки, выполненной во время установки.

      Выполнить сценарий набор-файлов.unpost_i, чтобы аннулировать результаты настройки, выполненной после установки.

4. Удалить из системы файлы данного набора и информацию о них.
5. Если файл набор-файлов.unconfig_d не существует:
   1. Для каждого установленного обновления данного набора файлов выполнить следующие действия:
      

      Выполнить любой сценарий набор-файлов.unpre_u, чтобы аннулировать результаты настройки, выполненной после установки.

   2. Для базового уровня набора файлов выполнить следующие действия:
      

      Выполнить любой сценарий набор-файлов.unpre_u, чтобы аннулировать результаты настройки, выполненной после установки.

6. Удалить все пустые каталоги, оставшиеся после удаления набора файлов.

   Примечание: Если во время выполнения сценария deinstal возникнет ошибка, информация о ней будет занесена в протокол, но выполнение сценария будет продолжено. Этим сценарий deinstal отличается от всех остальных сценариев команды installp, которые прекращают обработку набора файлов при возникновении ошибки. Однако при удалении набора файлов в случае ошибки наиболее разумное решение заключается в том, чтобы продолжать удаление.

Файл результатов установки

Команда installp определяет по файлу status результаты обработки этих наборов файлов. Если вы будете поставлять собственные сценарии установки, они должны создавать файл status в правильном формате. Каждая строка файла status должна содержать следующую информацию:

код-результатанабор-файлов

В поле код-результата могут быть указаны следующие значения:

Ниже приведен пример файла status, в котором указано, что наборы файлов tcp.client и tcp.server пакета bos.net были установлены успешно, а набор файлов nfs.client установить не удалось.

s bos.net.tcp.client
s bos.net.tcp.server
f bos.net.nfs.client

Команды, выполняемые во время установки и обновления программного обеспечения

Примеры применения этих команд можно найти в стандартном сценарии установки - /usr/lib/instl/instal.