Как создавать специфичные для платформы и независимые от платформы подпакеты RPM из одного .spec?

У меня есть файл dunno.spec со следующей структурой:

Name:                   dunno
Version:                 1.0
...
BuildArch:              x86_64

%description
...
%package common
Summary:                Shared files
BuildArch:              noarch

Я предполагаю, что после запуска rpmbuild -ba dunno.spec я должен получить два бинарных пакета:

  • dunno-1.0.x86_64.rpm
  • dunno-common-1.0.noarch.rpm

однако я получаю:

  • dunno-1.0.x86_64.rpm
  • dunno-common-1.0.x86_64.rpm

Если я уберу из спецификации строку BuildArch: x86_64, то получу

  • dunno-1.0.noarch.rpm
  • dunno-common-1.0.noarch.rpm

Как это исправить?

РПМ v4.4.2.3.


person dma_k    schedule 09.01.2015    source источник
comment
Хороший вопрос. Если это не сработало, я не уверен, что вы сможете это сделать. Хотя похоже, что это возможно в более новых версиях RPM, чем в CentOS 5.   -  person Etan Reisner    schedule 09.01.2015
comment
@EtanReisner: Не могли бы вы поделиться ссылкой, например, на что нового, описывающего, в какой версии RPM реализована эта функция?   -  person dma_k    schedule 09.01.2015
comment
Я не знаю. Я упомянул об этом только потому, что в CentOS 6 glib2.spec есть пакет noarch -doc. Это, кажется, первая версия с тегами из спецфайла Fedora, в котором он есть. Так что где-то между CentOS 5 4.4.2.3 и тем, что есть у F18. Это выглядит как 4.10.3.1. Но это огромный диапазон, и он мог быть где угодно.   -  person Etan Reisner    schedule 09.01.2015
comment
Да, пакет glib2 действительно имеет несколько разновидностей в репо. Будем надеяться, что эта функция не была введена патчем (их более 10, но все они кажутся несвязанными). Похоже, что единственное решение для версии 4.4 — запустить rmpbuild дважды.   -  person dma_k    schedule 09.01.2015


Ответы (3)


Разделите сборку на 2 пакета, один x86_64, другой noarch.

Вы можете сделать 2 сборки из одной спецификации, используя логику %ifarch (но обычно проще/чище использовать 2 файла спецификаций, даже если это раздражает).

Также нет ничего плохого в том, чтобы включить независимый от платформы контент в подпакет x86_64 вместо подпакета noarch.

person Jeff Johnson    schedule 09.01.2015
comment
В случае разделения мне нужно будет поддерживать другие общие поля, такие как Version, Url, License. Также сложность заключается в том, что общий персонал устанавливается во время цикла сборки, поэтому две спецификации вызовут два полных цикла сборки (нехорошо). Я, конечно, могу обмануть сборку, чтобы запустить легкий цикл сборки, но будет ли это концептуально правильным? Включение не повредит, но я скрыл часть истории: спецификация создает 3 зависимых от платформы бинарных пакета, все они зависят от общего независимого от платформы персонала (например, настроек). - person dma_k; 09.01.2015
comment
И как %ifarch может помочь? Например, если я добавлю %ifarch noarch, мне снова нужно будет запустить rpmbuild дважды (rpmbuild --target=x86_64 и rpmbuild --target=noarch). - person dma_k; 09.01.2015
comment
Я бы просто использовал все подпакеты x86_64 вместо того, чтобы пытаться использовать подпакет noarch. Многие пакеты x86_64 содержат только содержимое noarch. - person Jeff Johnson; 09.01.2015
comment
Да, %ifarch нужно будет собрать дважды, один раз для x86_64, один раз для noarch. Но версия: и т. д. будет идентичной и простой в обслуживании. - person Jeff Johnson; 09.01.2015
comment
Спасибо за комментарии. Я думаю, что для меня было бы разумно отказаться и иметь .x86_64 для всех пакетов. - person dma_k; 09.01.2015

Вы можете запустить rpmbuild, так как это rpmbuild --target=x86_64,noarh ..., а затем rpmbuild соберет пакет за два прохода для каждой арки.

person Ning Anzhou    schedule 17.10.2016

вы должны сделать dunno-common подпакетом

ваша спецификация должна выглядеть так

Name:                   dunno
Version:                 1.0
# next line is not needed
BuildArch:              x86_64

%package common
BuildArch:              noarch
Summary: ...
%description common
%files 
# ...

%files common
# ...

person Muayyad Alsadi    schedule 11.10.2020