findreq fix
Created attachment 962 [details] findreq fix
вдогонку про arch/noarch. в этом пакете есть gtk-doc.pc. pkgconfig живёт в разных директориях на i586 и x86_64 ввиду того, что .pc-файлы зачастую архитектурно-зависимые (содержат специфичные опции линковки). что делать?
(In reply to comment #2) > что делать? См. bug #7139
Не, ты не понял. Тут всё хуже. Дело в том, что каким-то волшебным образом, в gtk-doc есть файл pkgconfig, который в других пакетах arch-зависимый из-за возможных специфических параметров линковки и т.д. Поэтому, %_pkgconfigdir разворачивается в %_libdir/pkgconfig.
Вопрос тот же: нахрена в noarch-пакете %_lib раскрывается в lib64 в зависимости от --target ? У него же BuildArch: noarch, все target'ы при этом должны приводиться в noarch и макросы разворачиваются уже оттуда.
опять-двадцать пять. речь сейчас о том, что в пакете gtk-doc есть файл, который по определению бывает arch-зависимым. в разные дистрах вставляют разные костыли на эту тему. некоторые патчах pkgconfig, чтобы тот смотрел и в /usr/lib/pkgconfig, и в /usr/lib64/pkgconfig. некоторые просто фиксят rpm-post-скриптами pc-файлы так, чтобы там не было ни одного упоминания про %_libdir, %_x11libdir и т.д. rpm Vs. noarch -- это отдельная тема. Не говоря уже про pkgconfig. А gtk-doc, как я уже сказал, зафиксить нетрудно -- было бы желание. А судя по реакции его нет. Разве не так? Мне уже хватило баданий с xml-commons. я не отрицаю проблем с rpm, но где их нет? А заниматься перекидыванием стрелок -- так мы ничего никогда не решим и не сделаем.
(In reply to comment #6) > речь сейчас о том, что в пакете gtk-doc есть файл, который по определению бывает > arch-зависимым. Не понимаю, что значит "по определению". Если пакет noarch, какая может быть arch-зависимость? > rpm Vs. noarch -- это отдельная тема. Не говоря уже про pkgconfig. > А gtk-doc, как я уже сказал, зафиксить нетрудно -- было бы желание. Огласите список всех noarch-пакетов, которые держат что-либо в /usr/lib и которые нужно фиксить из-за просчета в системе макросов rpm. Просто лучше сразу оценить все трудозатраты. Может, ExclusiveArch: noarch как-нибудь поможет? Можно как-то ограничить выбор --target?
(In reply to comment #7) > Не понимаю, что значит "по определению". Если пакет noarch, какая может быть > arch-зависимость? Вспоминаем xml-commons... вспомнился? о чём там шла речь? Чем всё закончилось? Да, он стал полноценным noarch, но уже без %_libdir. Со всеми вытекающими. По определению - это значит, что данный файл _будет_ различаться при сборке пакета на _разных_ архитектурах. А то, что ему кто-то проставил noarch ещё ни о чём не говорит. Я могу и на glibc noarch поставить. Легче от этого станет? > Огласите список всех noarch-пакетов, которые держат что-либо в /usr/lib и > которые нужно фиксить из-за просчета в системе макросов rpm. Просто лучше сразу > оценить все трудозатраты. Я собираюсь зарядить на пересборку все noarch-пакеты на выходных. Тогда и будет список того, что возможно не noarch. Критерия два: собираемость (с учётом удовлетворённых зависимостей) и идентичность вновь собранных на x86_64 с "эталонными" в Сизифе. Я тут уже натыкался на пакеты, которые не желают без каких-либо видимых причин собираться под x86_64. > Может, ExclusiveArch: noarch как-нибудь поможет? Можно как-то ограничить выбор > --target? А что это изменит? Посмотрите, что из себя представляет /usr/lib/noarch-* - это симлинк на arch.
(In reply to comment #8) > Вспоминаем xml-commons... вспомнился? о чём там шла речь? Чем всё закончилось? > Да, он стал полноценным noarch, но уже без %_libdir. Там все было проще: расположением файлов я могу всецело управлять. Файлы для pkgconfig по конвенции должны быть в @libdir@/pkgconfig и с этим ничего не сделать. > По определению - это значит, что данный файл _будет_ различаться при сборке > пакета на _разных_ архитектурах. А то, что ему кто-то проставил noarch ещё ни о > чём не говорит. И как конкретно будет различаться этот файл для gtk-doc?
(In reply to comment #9) > Там все было проще: расположением файлов я могу всецело управлять. > Файлы для pkgconfig по конвенции должны быть в @libdir@/pkgconfig и с этим > ничего не сделать. А что должно быть для noarch? Если сам pkgconfig ищет именно в @libdir@/pkgconfig. Но при этом @libdir@ различен для arch/noarch? > И как конкретно будет различаться этот файл для gtk-doc? Я говорил про pc-файлы в целом. Посмотрите на файл /usr/lib/pkgconfig/glib-2.0.pc для примера. Можно было бы и вырезать libdir, а при работе pkgconfig его подставлять, но вот Cflags имеет право быть завязанным на архитектуру. Хотя, я пока таких не встречал.
(In reply to comment #10) > А что должно быть для noarch? Если сам pkgconfig ищет именно в > @libdir@/pkgconfig. Но при этом @libdir@ различен для arch/noarch? Угу. Для noarch он должен раскрываться в lib _без_вариантов_. > > И как конкретно будет различаться этот файл для gtk-doc? > Я говорил про pc-файлы в целом. В целом по больнице неинтересно. pkgconfig для архитектурно-независимых пакетов различаться заведомо не может. Загляните в gtk-doc.pc
(In reply to comment #11) > Угу. Для noarch он должен раскрываться в lib _без_вариантов_. ... > В целом по больнице неинтересно. pkgconfig для архитектурно-независимых пакетов > различаться заведомо не может. Загляните в gtk-doc.pc У вас есть уже готовые предложения по _правильному_ поведению pkgconfig?
(In reply to comment #12) > У вас есть уже готовые предложения по _правильному_ поведению pkgconfig? К pkgconfig никаких претензий нет: если он ищет свои файлы в пути /usr/lib/pkgconfig:/usr/lib64/pkgconfig, пускай себе. Все претензии к макросам rpm, по которым конфигурация noarch пакета меняется в зависимости от параметра --target, что есть полнейший нонсенс.
Fixed in 1.4-alt1 Сделал проще: фальшивый Provides: perl(gtkdoc-common.pl)
Вдогонку по pkg-config: gtk-doc-1.4-alt2 помещает .pc в /usr/share/pkgconfig. Новый pkg-config умеет там искать.
В догонку про pkgconfig: что будет с %_pkgconfigdir?
Народ в devel@ это уже обсудил. Т.ч.это ещё один повод собрать rpm с нормальным noarch... Ток нужно ещё зафиксить, чтоб rpm подсасывал нужные макросы при выставлени в спеке BuildArch, оверрайдя --target
