Bug 7253 - findreq fix
: findreq fix
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/gtk-doc)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
: 7139 7315
:
  Show dependency tree
 
Reported: 2005-06-30 17:09 by
Modified: 2007-10-02 22:25 (History)


Attachments
findreq fix (1.04 KB, application/octet-stream)
2005-06-30 17:11, Kachalov Anton
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-06-30 17:09:07
findreq fix
------- Comment #1 From 2005-06-30 17:11:08 -------
Created an attachment (id=962) [details]
findreq fix
------- Comment #2 From 2005-06-30 17:24:48 -------
вдогонку про arch/noarch.
в этом пакете есть gtk-doc.pc.
pkgconfig живёт в разных директориях на i586 и x86_64 ввиду того, что .pc-файлы
зачастую архитектурно-зависимые (содержат специфичные опции линковки).
что делать?
------- Comment #3 From 2005-07-07 09:24:58 -------
(In reply to comment #2)
> что делать?

См. bug #7139
------- Comment #4 From 2005-07-07 11:03:33 -------
Не, ты не понял. Тут всё хуже. Дело в том, что каким-то волшебным образом, в
gtk-doc есть файл pkgconfig, который в других пакетах arch-зависимый из-за
возможных специфических параметров линковки и т.д. Поэтому, %_pkgconfigdir
разворачивается в %_libdir/pkgconfig.
------- Comment #5 From 2005-07-07 23:05:52 -------
Вопрос тот же: нахрена в noarch-пакете %_lib раскрывается в lib64 в зависимости
от --target ? У него же BuildArch: noarch, все target'ы при этом должны
приводиться в noarch и макросы разворачиваются уже оттуда.
------- Comment #6 From 2005-07-08 00:37:29 -------
опять-двадцать пять.
речь сейчас о том, что в пакете gtk-doc есть файл, который по определению бывает
arch-зависимым. в разные дистрах вставляют разные костыли на эту тему. некоторые
патчах pkgconfig, чтобы тот смотрел и в /usr/lib/pkgconfig, и в
/usr/lib64/pkgconfig. некоторые просто фиксят rpm-post-скриптами pc-файлы так,
чтобы там не было ни одного упоминания про %_libdir, %_x11libdir и т.д.

rpm Vs. noarch -- это отдельная тема. Не говоря уже про pkgconfig.
А gtk-doc, как я уже сказал, зафиксить нетрудно -- было бы желание. А судя по
реакции его нет. Разве не так? Мне уже хватило баданий с xml-commons.
я не отрицаю проблем с rpm, но где их нет? А заниматься перекидыванием стрелок
-- так мы ничего никогда не решим и не сделаем.
------- Comment #7 From 2005-07-08 00:45:25 -------
(In reply to comment #6)
> речь сейчас о том, что в пакете gtk-doc есть файл, который по определению бывает
> arch-зависимым.

Не понимаю, что значит "по определению". Если пакет noarch, какая может быть
arch-зависимость?

> rpm Vs. noarch -- это отдельная тема. Не говоря уже про pkgconfig.
> А gtk-doc, как я уже сказал, зафиксить нетрудно -- было бы желание.

Огласите список всех noarch-пакетов, которые держат что-либо в /usr/lib и
которые нужно фиксить из-за просчета в системе макросов rpm. Просто лучше сразу
оценить все трудозатраты.

Может, ExclusiveArch: noarch как-нибудь поможет? Можно как-то ограничить выбор
--target?
------- Comment #8 From 2005-07-08 01:13:36 -------
(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.
------- Comment #9 From 2005-07-08 10:36:55 -------
(In reply to comment #8)
> Вспоминаем xml-commons... вспомнился? о чём там шла речь? Чем всё закончилось?
> Да, он стал полноценным noarch, но уже без %_libdir.

Там все было проще: расположением файлов я могу всецело управлять.
Файлы для pkgconfig по конвенции должны быть в @libdir@/pkgconfig и с этим
ничего не сделать.

> По определению - это значит, что данный файл _будет_ различаться при сборке
> пакета на _разных_ архитектурах. А то, что ему кто-то проставил noarch ещё ни о
> чём не говорит.

И как конкретно будет различаться этот файл для gtk-doc?
------- Comment #10 From 2005-07-08 11:43:46 -------
(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 имеет право быть завязанным
на архитектуру. Хотя, я пока таких не встречал.
------- Comment #11 From 2005-07-08 12:03:24 -------
(In reply to comment #10)
> А что должно быть для noarch? Если сам pkgconfig ищет именно в
> @libdir@/pkgconfig. Но при этом @libdir@ различен для arch/noarch?

Угу. Для noarch он должен раскрываться в lib _без_вариантов_.

> > И как конкретно будет различаться этот файл для gtk-doc?
> Я говорил про pc-файлы в целом.

В целом по больнице неинтересно. pkgconfig для архитектурно-независимых пакетов
различаться заведомо не может. Загляните в gtk-doc.pc
------- Comment #12 From 2005-07-08 12:25:23 -------
(In reply to comment #11)
> Угу. Для noarch он должен раскрываться в lib _без_вариантов_.
...
> В целом по больнице неинтересно. pkgconfig для архитектурно-независимых пакетов
> различаться заведомо не может. Загляните в gtk-doc.pc
У вас есть уже готовые предложения по _правильному_ поведению pkgconfig?
------- Comment #13 From 2005-07-08 15:13:56 -------
(In reply to comment #12)
> У вас есть уже готовые предложения по _правильному_ поведению pkgconfig?

К pkgconfig никаких претензий нет: если он ищет свои файлы в пути
/usr/lib/pkgconfig:/usr/lib64/pkgconfig, пускай себе.

Все претензии к макросам rpm, по которым конфигурация noarch пакета меняется в
зависимости от параметра --target, что есть полнейший нонсенс.
------- Comment #14 From 2005-07-26 10:35:22 -------
Fixed in 1.4-alt1

Сделал проще: фальшивый Provides: perl(gtkdoc-common.pl)
------- Comment #15 From 2005-09-10 17:10:41 -------
Вдогонку по pkg-config: gtk-doc-1.4-alt2 помещает .pc в /usr/share/pkgconfig.
Новый pkg-config умеет там искать.
------- Comment #16 From 2005-09-10 20:11:41 -------
В догонку про pkgconfig: что будет с %_pkgconfigdir?
------- Comment #17 From 2005-09-10 20:21:53 -------
Народ в devel@ это уже обсудил.
Т.ч.это ещё один повод собрать rpm с нормальным noarch... Ток нужно ещё
зафиксить, чтоб rpm подсасывал нужные макросы при выставлени в спеке BuildArch,
оверрайдя --target