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