В файле спецификации RPM, когда файл не найден, как узнать, какая строка%files виновата?

Question

В файле спецификации RPM, когда файл не найден, как узнать, какая строка%files виновата?

Я работаю с очень тяжелым файлом спецификации RPM, и при сборке он выдает ошибку, которую я не могу отследить:

File not found: /var/tmp/pkgnamehere/mockbuild/usr/com/pgsql

(Я заменил полный путь сборки пакета на "pkgnamehere" выше, но в остальном он не редактировался).

Нет никаких /usr/com/pgsql нигде в% файлов, ни на самом деле любой /com/ совсем.

Предположительно, это результат расширения макроса. Беда в том... как узнать, какие %files строка соответствует заданному отсутствующему файлу? Там не написано "Файл из% файлов в строке 554 не найден: " или что-нибудь полезное подобное.

Многие из фактических %files линии выглядят так:

%config(noreplace) %{_initrddir}/%{oname}-%{majorversion}

поэтому простой текстовый поиск здесь не нужен.

Можно rpm --eval каждая строка, но это довольно болезненно с более чем 300 строками файлов и необходимостью определить все входные макросы.

Подсказки?

$ rpm --version
RPM version 4.11.2
$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-ia32:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-ia32:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-ia32:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: Fedora
Description:    Fedora release 20 (Heisenbug)
Release:        20
Codename:       Heisenbug
$ mock --version
1.1.41

Предоставлено таким SO ответом, rpmspec -P расширит и распечатает спецификацию. Тем не менее, он не пролил никакого света:

$ rpmspec -P unified-rpm/postgresql94.spec | grep '/com/'
$

в этом, кажется, здесь есть загадочный файл.

Предоставлено таким SO ответом, rpmspec -P расширит и распечатает спецификацию.

На сборочной машине все выглядело хорошо - тогда я понял, что это действительно проблема в CentOS 5 mock песочница.

Там нет rpmspecтак что не легко сказать, что случилось. Однако я наткнулся на эту ошибку, которая предполагает, что это проблема с RPM на RHEL5. Конечно же, в песочнице:

<mock-chroot>[root@ayaki BUILD]# rpm --eval '%_sharedstatedir'
/usr/com

на что я говорю.... что!?

Таким образом, немедленная проблема может быть решена с помощью:

%if 0%{rhel5}
%define _sharedstatedir /var/lib
%endif

или возможно:

%if "%{_sharedstatedir}" == "/usr/com"
# See https://bugzilla.redhat.com/show_bug.cgi?id=894903
%define _sharedstatedir /var/lib
%endif

... но в любом случае, основной вопрос остается: как вы получаете RPM, чтобы сказать вам, какие %files строка соответствует отсутствующему файлу?

0

rpm specfile

Источник

Craig Ringer 13 авг '14 в 04:52

1 ответ

Решение

Другие вопросы по тегам rpm specfile

Michael Hampton 13 авг '14 в 12:12 2014-08-13 12:12 · Accepted Answer · 2014-08-13 12:12

Проблема не в Fedora 20 и не в Mock. Это 5 РЕЛ.

Макрос RPM %{_sharedstatedir} был установлен на %{prefix}/com и в RHEL 4, и в RHEL 5. Проблема в том, что макрос никогда не использовался для построения этих дистрибутивов, поэтому никто не обращал внимания на его ценность. Это стало проблемой только тогда, когда люди начали создавать бэкпорты из более поздней Fedora, которая использовала макрос.

И, конечно же, поскольку RHEL - это "стабильный" корпоративный дистрибутив, который стремится не нарушать совместимость в течение своего жизненного цикла, это никогда не изменится.

Макрос работает так, как вы ожидаете в RHEL 6 и 7.

Если вам все еще нужно поддерживать блоки RHEL 5, вы (и все остальные) застряли с обходными путями, подобными тем, которые вы уже предложили. Простой и чистый - первый, который вы предложили:

%if 0%{rhel5}
%define _sharedstatedir /var/lib
%endif

Я не вижу смысла ссылаться на эту конкретную ошибку, поскольку она фактически не объясняет проблему и не дает обходного пути.