Как мне написать макрос RPM, который расширяется до набора дополнительных макросов?

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

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

Это подводит меня к моему вопросу:

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

%dependency -B libstrutil -M 1 -m 5 -p 0

который расширится до:

%define libstrutil     libstrutil.so
%define libstrutil_m   libstrutil.so.1
%define libstrutil_mm  libstrutil.so.1.5
%define libstrutil_mmp libstrutil.so.1.5.0

Где опция «-B» - это базовое имя библиотеки, опция «-M» - это основной номер версии, «-m» - это дополнительный номер версии, а «-p» - это уровень исправления. Затем эти макросы можно использовать во всем файле спецификации, где могут потребоваться определенные версии (особенно в разделе% files).

Я просмотрел макросы, поставляемые с RHEL 6 (особенно / usr / lib / rpm / macros), но нашел очень мало примеров макросов с аргументами. Я нашел ОДИН% GNUconfigure, и это не совсем просто, учитывая, что в его определении используется много условной логики. Более актуально для непосредственного вопроса,% GNUconfigure сам по себе не определяет другие макросы.

Я подозреваю, что то, что я пытаюсь сделать, достигается с помощью% {expand: ...}, но я даже не приблизился к тому, чтобы заставить этот синтаксис работать.


rpmbuild rpm rpm-spec
person Jeff W    schedule 05.03.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Не уверен, что вам нужно самостоятельно расширять линейки. rpm может с этим справиться, если вы вернете строки %define.

Если это правда, то это может сработать:

%dependency(B:M:m:p:) \
    %%define %{-B*} %{-B*}.so \
    %%define %{-B*}_m %{-B*}.so.%{-M*} \
    %%define %{-B*}_mm %{-B*}.so.%{-M*}.%{-m*} \
    %%define %{-B*}_mmp %{-B*}.so.%{-M*}.%{-m*}.%{-p*}

В противном случае вам могут понадобиться:

%dependency(B:M:m:p:) \
    %{expand:%%define %{-B*} %{-B*}.so} \
    %{expand:%%define %{-B*}_m %{-B*}.so.%{-M*}} \
    %{expand:%%define %{-B*}_mm %{-B*}.so.%{-M*}.%{-m*}} \
    %{expand:%%define %{-B*}_mmp %{-B*}.so.%{-M*}.%{-m*}.%{-p*}}

Любому из них может потребоваться использовать %global вместо %define. (К сожалению, я не совсем понимаю, когда они отличаются.)

person Etan Reisner    schedule 05.03.2015
comment
макросы имеют автоматическую сборку мусора. поэтому% global добавляет на уровне 0, а% define добавляет на текущем уровне вложенности рекурсии. - person Jeff Johnson; 08.03.2015
comment
@JeffJohnson Итак, %{expand} существует уровень рекурсии n + 1, и тогда нужно / нужно %global? И рекурсия неявная, когда значение включает другой макрос? Или только в определенных местах? (Это то, что я никогда полностью не понимал.) - person Etan Reisner; 09.03.2015
comment
% global никогда не повредит и, скорее всего, это то, чего все ожидают. Каждая рекурсия вновь обнаруженного макроса происходит на уровне + 1, который используется для сборки мусора для любых обнаруженных% определений. % global никогда не будет собираться мусором. . % expand на самом деле является маркером в буфере расширения для продолжения в начале, а не в конце его расширенного аргумента. уровни расширения будут такими же при перезапуске - person Jeff Johnson; 11.03.2015