Если дело начато с идеи сборки пакета для нескольких версий Linux, можно установить такое окружение сборки, которое поможет четко разделить вендор-зависимые характеристики.
Ключевые темы в данном подходе:
* Определение вендора
* Использование макросов для задания процесса сборки
* Обработка различных зависимостей
18.2.5.1 Определение вендора
Для получения чистой среды сборки необходима возможность определения вендора, и, в зависимости от этого, нужных установок при сборке. Для облегчения решения этой задачи большинство вендоров помещают в определенное место файловой системы файл или устанавливают специальный пакет, который содержит имя производителя. Это имя может быть получено в процессе сборки.
Соглашение для файлов следующее:
/etc/vendor-release |
Например:
$ more /etc/redhat-release |
Для пакетов соглашение касается имен пакетов:
$ rpm -q redhat-release |
Также можно использовать простое определение макроса для имени вендора и затем опцию --define для rpmbuild. Например:
# rpmbuild ba --define 'linuxVendor suse' |
С такой опцией используется макрос %linuxVendor.
Альтернативный подход - автоматическое определение вендора скриптами сборки. Ручное определение работает, однако требует введения информации от пересборщика пакета.
18.2.5.2 Построение окружения сборки и макросов
Будучи единожды установленным, значение макроса "вендор" позволяет задать другие макросы, учитывающие различия дистрибутивов, которые влияют на ваши приложения.
Для учета платформы используют главным образом условные определения, заключенные между %if и %endif. Кроме того, часто бывает полезным использование опций --with, --without и --target утилиты rpmbuild, позволяющие контролировать особенности сборки путем передачи условий в скрипты и макросы, определенные в spec-файле.
Макрос %if позволяет задать условия. Например:
%if %{old_5x} && %{old_6x} |
Также %if можно использовать для настройки таких полей, как
Requires: (показано в нижеследующем примере):
%if %{build6x} |
Опция командной строки --with задает значение специального макроса _with_. Например, следующая команда вносит установки в макросы spec-файла:
Также %if можно использовать для настройки таких полей, как
Requires: (показано в нижеследующем примере):
$ rpmbuild bc --with ssh filename.spec |
В этом примере значение макроса _with_ssh будет установлено в значение --with-ssh. Этот формат задан специально для конфигурирования в стиле GNU (формат опции скрипта configure). Такой подход широко используется для условной, платформеннозависимой сборки.
Подобно опции --with, опция командной строки --without определяет значение специального макроса with _without_. Он определяет области кода, которые не будут использованы.
Часто комбинируют --with и --without для повышения гибкости этого шаблона. Кроме того, ветвление можно образовать с помощью проверки значения. Например:
./configure %{?_with_ssh} |
Если макрос _with_ssh определен, команда будет такой:
./configure --with-ssh |
Если макрос не определен, тогда такой:
./configure |
Опция командной строки --target в свою очередь определяет макросы %_target, %_target_arch и %_target_os. Например:
$ rpmbuild -bc --target ppc-ibm-aix /usr/src/redhat/SPECS/jikes.spec |
18.2.5.3 Пакеты совместимости (compatibility packages) и ассоциативные пакеты (glue packages)
Все дистрибутивы Linux имеют отличия. Только макросы не в состоянии покрыть все эти отличия для полной унификации сборки и получаемых пакетов. Тем не менее проблемы должны быть решены и многие из них решаются с помощью пакетов совместимости и ассоциативных пакетов.
Пакет совместимости предоставляет старый, унаследованный API для новой системы, которая больше не поддерживает старый API. В соответствии с соглашением пакеты совместимости для основного пакета именуются compat-имя_пакета.
Например:
$ rpm -q --qf "%{description}" compat-libstdc++ |
Использование compat- пакетов позволяет создавать программы, использующие подход наименьшего общего знаменателя и программировать для старых, но наиболее общих API. Если некоторые дистрибутивы исключают пакеты со старыми API, compat- пакеты могут предоставить эти API.
Подобно compat- пакетам, ассоциативные или glue- пакеты предоставляют зависимости, которые присутствуют в одних дистрибутивах и отсутствуют в других. Они помогают "приклеить" ваш пакет к конкретному дистрибутиву, в котором недостает нужных зависимостей.
Основная цель пакетов совместимости и ассоциативных пакетов - в как можно большей степени оставить исходный пакет приложения в неприкосновенности, чтобы он был как можно ближе к версии вендора, выпустившего пакет. compat- и glue- подходы позволяют обеспечить работоспособность исходного приложения в других системах.
Таким образом, приложения, разработанные для Linux демонстрируют высокую степень адаптивности к разным дистрибутивам, кроме того, огромный пул ПО работоспособен (и имеются соответствующие бинарные пакеты) на различных процессорных архитектурах, таких как SPARC, MIPS, ARM.
Далее - Работа с не-rpmbased дистрибутивами
Назад - Создание пакетов с переопределимыми путями
Содержание