Итак, RPM теперь портирован на целевую платформу и установлен. Первым шагом в работе с RPM является инициализация БД RPM, включающая два шага:

* Инициализация пустой базы

* Наполнение базы информацией о пакетах, в особенности в контексте зависимостей

19.3.1.1 Инициализация пустой БД RPM
Пустая база создается с помощью опции --initdb:

# mkdir /var/lib/rpm # rpm --initdb

Первая команда создает каталог для хранения БД (путь по умолчанию). Если будет использоваться иной путь, необходимо передать его в параметрах, как показано ниже:

# rpm --dbpath /location/of/your/rpm/database --initdb

Кроме того, можно использовать опцию v для повышения информативности вывода, что сильно помогает при возникновении ошибок.

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

Для указания набора rc файлов, отличного от умолчального, используется опция --rcfile, пользовательского набора макросов - опция --macros.

Наполнение пустой БД информацией о пакетах в большинстве случаев сводится к установке новых пакетов и происходит автоматически средствами RPM.

19.3.1.2 Обработка зависимостей пакетов, установленных без участия системы RPM
Всякий раз, когда устанавливается новый пакет, информация о нем попадает в БД RPM. Это хорошо работает, если все зависимости вновь устанавливаемого пакета уже установлены.

В rpmbased операционных системах, таких как Red Hat Linux, все пакеты за исключением некоторого количества стартовых механизмов, устанавливаются через RPM. Это означает, что практически вся система отражена в БД, RPM "знает" обо всех установленных пакетах и может правильно обрабатывать зависимости. Таким образом, ошибки при обработке зависимостей означают, что нужные пакеты не установлены.

В операционных системах, которые не базируются на RPM, таких как Solaris или IRIX, большинство пакетов установлены помимо системы RPM, поскольку эти операционные системы имеют собственные службы пакетного менеджмента. Поэтому, если rpm-пакеты, которые имеется в виду установить, зависят от ПО, поставляющегося как-то иначе, чем в rpm-пакетах, такие случаи можно считать удачными. Например, утилита rpm для Windows зависит от cygwin, а cygwin имеет собственный инсталлятор setup.exe и не зависит от наличия или отсутствия RPM.

Следовательно, для правильной обработки зависимостей необходимо наполнить БД RPM такой информацией, которая отражает текущее состояние системы. Основной путь здесь - установка виртуального пакета.

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

Для создания виртуального пакета используется скрипт vpkg-provides.sh из каталога скриптов. Этот скрипт обходит каталоги в поисках разделяемых библиотек и интерпретаторов. Затем формируется список, помещаемый в spec-файл. Список содержит все найденные ресурсы (но это список файлов а не пакетов). Для наполнения БД RPM информацией о предоставляемых системой возможностях, на основе этого spec-файла собирается пакет, который устанавливается уже посредством утилиты rpm.

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

Скрипт vpkg-provides.sh принимает три основных опции: --spec_header, --ignore_dirs и --no_verify.

Опция --spec_header передает имя spec-файла, который будет использоваться в качестве шаблона для вновь создаваемого spec-файла. Например:

# sh vpkg-provides.sh --spec_header /path/to/spec/file

Шаблон нужен для генерации полного spec-файла. Шаблон должен содержать как минимум поля Summary, Name, Version и Release.

Опция --ignore_dirs говорит скрипту, какие каталоги необходимо пропустить. Для формирования списка пропускаемых каталогов передается шаблоны поиска egrep. Шаблоны разделяются символом вертикальной черты. Если egrep в системе недоступен, следует отредактировать скрипт vpkg-provides.sh, внеся в нужном месте список каталогов для игнорирования вручную.

Опция --no_verify позволяет пропустить шаг создания скрипта для проверки контрольных сумм всех найденных файлов.

Кроме главных опций имеются дополнительные:

Опция --shlib_dirs указывает на каталоги с разделяемыми библиотеками, список составляется в одну строку в двойных кавычках с двоеточием в качестве разделителя:

# sh vpkg-provides.sh --spec_header /path/to/spec/file \ --shlib_dirs "/bin:/usr/bin:/sbin:/usr/sbin:/usr/ucb:/usr/bsd"

Опция --interp_dirs говорит, в каких каталогах искать интерпретаторы, например, sh, bash, perl, awk. В свою очередь опция --interps используется для перечисления этих интерпретаторов. Обе эти опции ожидают для ввода строку с двоеточиями между параметрами.

Опция --find_provides указывает на расположение скрипта find-provides (по умолчанию /usr/lib/rpm/find-provides).

Скрипт vpkg-provides.sh находит каталоги с разделяемыми библиотеками и интерпретаторами в различных операционных системах. Как правило, бывает необходимо отредактировать соответствующую секцию в скрипте.

Если вы работаете с не-Unix системой, или при запуске скрипта возникают ошибки, можно редактировать скрипт в целях удаления проблемных команд. Также на основе vpkg-provides.sh можно создать новый сценарий на языке, поддерживаемом целевой системой. Некоторые системы могут не поддерживать не только системные команды, которые вызываются из скрипта, но и сам язык shell. vpkg-provides.sh проделывает значительное количество действий, направленных только на то, чтобы скрипт был максимально универсальным. Эта работа может быть сокращена путем прямого указания каталогов, команд и тому подобных параметров. Кроме того, можно вообще не использовать vpkg-provides.sh, а собрать виртуальный пакет вручную.

После завершения всех действий скрипт выдает spec-файл, в котором содержится и переданный ему шаблон, и список строк, каждая из которых содержит зависимость для будущих пакетов. Кроме того выводится несколько пустых определений для заполнения секций prep, build, install и clean.

Пример выполнения vpkg-provides.sh:

$ sh ./vpkg-provides.sh --spec_header my_header.spec --find_provides ./find-provides --no_verify Provides: /bin/sh Provides: /bin/csh Provides: /bin/ksh Provides: /bin/perl Provides: /bin/awk Provides: /bin/nawk Provides: /bin/oawk Provides: /usr/bin/sh Provides: /usr/bin/csh Provides: /usr/bin/ksh Provides: /usr/bin/perl Provides: /usr/bin/awk Provides: /usr/bin/nawk Provides: /usr/bin/oawk Provides: /sbin/sh Provides: /usr/dt/bin/dtksh Provides: /usr/xpg4/bin/sh Provides: /usr/xpg4/bin/awk %prep # nothing to do %build # nothing to do %install # nothing to do %clean # nothing to do %files # no files in a virtual package

Также добавляется описание пакета, содержащее информацию о том, как пакет был собран.

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

19.3.1.4 Создание виртуального пакета вручную
Проблемы автоматизированной генерации spec-файла для виртуального пакета могут возникнуть и на Unix-подобных системах, так как vpkg-provides.sh ожидает, что ряд утилит Unix и GNU будут доступны.

Если же замена команд и прямое указание нужных параметров не дает эффекта, следует написать spec-файл вручную. Добавьте Provides: для каждой библиотеки и интерпретатора в шаблон spec-файла, например:

Provides: libgen.so

Скопируйте пустые секции prep, build, install, и clean как показано в примерах, запустите rpmbuild для сборки пакета и установите его.

Далее - Настройка окружения RPM
Назад - Решение проблем
Содержание