Итак, RPM теперь портирован на целевую платформу и установлен. Первым шагом в работе с RPM является инициализация БД RPM, включающая два шага:
* Инициализация пустой базы
* Наполнение базы информацией о пакетах, в особенности в контексте зависимостей
19.3.1.1 Инициализация пустой БД RPM
Пустая база создается с помощью опции --initdb:
|
# mkdir /var/lib/rpm |
Первая команда создает каталог для хранения БД (путь по умолчанию). Если будет использоваться иной путь, необходимо передать его в параметрах, как показано ниже:
|
# 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 |
Также добавляется описание пакета, содержащее информацию о том, как пакет был собран.
Далее с помощью созданного 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
Назад - Решение проблем
Содержание