Спецификация rpm: Как подавить ошибку «Макрос расширен в комментарии», не удаляя ссылку?
При устранении проблем с файлами RPM .spec часто бывает удобно комментировать строки из раздела %files:
%files
#%{_datadir}/vala/vapi/libgdaui-%{apiver}.vapi
Однако это может привести к следующим ошибкам сборки:
Macro expanded in comment on line 213: %{_datadir}/vala/vapi/libgdaui-%{apiver}.vapi
Вопрос
Есть ли способ сообщить rpmbuild о завершении сборки и рассматривать «Макрос, развернутый в комментарии», как предупреждение, а не как ошибку?
исх. github.com/rpm-software-management/rpm/blob/…
rpm >= 4.15 имеет настоящий примитив комментирования в виде %dnl, вдохновленного M4 (отбросить на следующую строку). Как следует из названия, он просто отбрасывает все до следующей новой строки, а макросы в отброшенной части, естественно, не расширяются (благодарность Пану Матилайнену).
Ответы 1
Это уже предупреждение, а не ошибка. В разделе %files, где макросы относятся к тому типу, который вы показываете (расширяющемуся до подмножества одного пути, а не списка путей), это безвредно. Проигнорируйте это или удвойте свои % (как советуют в документах), чтобы этого не произошло (а затем отмените это при раскомментировании того же контента).
Только сообщения журнала с уровнем CRIT вызывают автоматический сбой сборки. Сообщения журнала с уровнем WARN даже близко не стоят.
Вы также можете рассмотреть возможность использования макросов вместо комментариев для временного отключения функций (%if 0).
Цитата из исходного кода RPM:
if (*bufA != '\0' || *bufB != '\0')
rpmlog(RPMLOG_WARNING,
_("Macro expanded in comment on line %d: %s\n"),
spec->lineNum, bufA);
Как видите, единственное, что мы делаем при обнаружении случая, — это регистрируем предупреждение и ничего больше.
Хорошее замечание о возможной проблеме многострочного расширения. При выходе я получал сообщение об ошибке «Не удалось построить RPM», и в нем были перечислены все предупреждения Macro expanded in comment, поэтому, возможно, я неправильно прочитал сообщение. Мне удалось собрать пакет с успешными комментариями, содержащими макросы, поэтому спасибо за ваш подробный ответ.
Это не всегда безвредно. Если бы макрос, который он расширял, был многострочным, то была бы отключена только первая строка макроса. Остальная часть макроса попытается его выполнить. Правильное решение — увеличить %% вдвое.
@AaronD.Marasco, цитирую ответ, на который вы ответили: где макросы имеют тот тип, который вы показываете (расширяющийся до подмножества одного пути, а не списка путей) - было ли это предостережение каким-то недостаточным? Да, конечно, экранирование % — правильный подход, но я не ожидаю, что кто-нибудь откажется от ярлыков редактора для (не)комментирования во время быстрой отладки, когда в этом нет строгой необходимости (конечно, перед отправкой готовой работы в исходный код, да , вполне уместный вопрос).
@AaronD.Marasco, действительно, если вы посмотрите на комментарий непосредственно перед вашим, который ОП добавил к этому ответу, вы увидите, что они признали понимание того, что макросы, расширяющиеся до нескольких строк, могут вызвать проблемы, поэтому нет никаких сомнений в том, что это было явно общался!
Другая проблема — код в комментарии. Строка #%global foo something%(touch /tmp/foo) игнорируется как комментарий, но макрос выполняется. Итак, файл /tmp/foo создан. А если вместо touch у вас будет какой-то странный rm, то у вас будут большие проблемы...
@msuchy, ... я не испытываю особой симпатии к людям, которые не могут помещать свои сборки в песочницу. (В основном я живу в мире NixOS — в прошлой жизни, когда я использовал Nix для создания образов дистрибутивов, отличных от Nix, первый раз запускал виртуальную машину qemu только с объявленными зависимостями для каждого пакета, а затем запускал каждый сборка отдельного пакета в переходном режиме, когда изменения на диске никогда не покидают память, а окончательные двоичные файлы копируются через файловую систему virtio, предназначенную для этой цели)
Если посмотреть на исходный код RPM, то это не ошибка сборки, а предупреждение. Имейте в виду, что это предупреждение может вызвать ошибку, если ваш макрос разворачивается на несколько строк - очень часто, когда первая строка закомментирована, оставшаяся часть не будет действительным исполняемым кодом - но это не относится к файлам. раздел, поэтому в этом конкретном контексте предупреждение можно игнорировать.