[devel] pkg-config Requires.private - полчища саранчи и враги народа

[devel] pkg-config Requires.private - полчища саранчи и враги народа

[Alexey Tourbin]

Некоторые пакеты из freedesktop.org испортили враги народа -
они переместили pkgconfig зависимости из Requires в Requires.private.
По их логике, если программа не линкуется напрямую с дополнительными
библиотеками, то в Requires их указывать не надо.  Но в то же время
при компиляции могут включаться хедеры дополнительных библиотек.
Так что сборка пакетов стала ломаться из-за отсутствия нужных хедеров,
и в rpm 4.0.4-alt100.2 пришлось приравнять Requires.private к Requires.
В результате многие пакеты обросли лишними pkgconfig зависимостями на
*-devel пакеты.

Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
1) Оставлять в зависимостях только Requires, а Requires.private убрать.
2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры
включаются, чтобы появились дополнительные зависимости на *-devel
пакеты с хедерами.  Скрипт cpp.req был написан почти три года назад,
но в нём не было необходимости, т.к. pkgconfig.req давал неплохой
результат.  Никогда не знаешь, чего придётся доставать из штанин.

Вот примеры того, как изменятся зависимости.

$ compare_packages -i -a -R libXft-devel-2.2.0-alt3.x86_64.rpm
--- /tmp/.private/at/compare_packages.GHMfrhdqbY/1      2011-02-27 17:20:58.018880241 +0300
+++ /tmp/.private/at/compare_packages.GHMfrhdqbY/2      2011-02-27 17:20:58.006881010 +0300
@@ -1,7 +1,8 @@
 /usr/lib64/pkgconfig
+fontconfig-devel
 libXft = 2.2.0-alt3
-pkgconfig(fontconfig)
-pkgconfig(freetype2)
+libXrender-devel
+libfreetype-devel
 pkgconfig(xproto)
-pkgconfig(xrender)
 rpmlib(PayloadIsLzma)
+xorg-xproto-devel
$

Здесь зависимости, по сути, не изменились: убрались pkgconfig зависимости
из Requires.private, но добавились сходные зависимости, полученные через
cpp.req.  Мы просто отыграли то, что испортили враги народа.

$ compare_packages -i -a -R libcairo-devel-1.10.2-alt2.x86_64.rpm
--- /tmp/.private/at/compare_packages.yWch2sMnSM/1      2011-02-27 17:24:39.507763649 +0300
+++ /tmp/.private/at/compare_packages.yWch2sMnSM/2      2011-02-27 17:24:39.491765038 +0300
@@ -1,14 +1,16 @@
 /usr/lib64/pkgconfig
+fontconfig-devel
 libGL-devel
+libX11-devel
+libXrender-devel
 libcairo = 1:1.10.2-alt2
+libfreetype-devel
+libxcb-devel
 pkgconfig(fontconfig) >= 2.2.95
 pkgconfig(freetype2) >= 9.7.3
 pkgconfig(gl)
-pkgconfig(glib-2.0)
-pkgconfig(gobject-2.0)
 pkgconfig(libpng)
 pkgconfig(libudev) >= 136
-pkgconfig(pixman-1) >= 0.18.4
 pkgconfig(x11)
 pkgconfig(xcb) >= 1.1.92
 pkgconfig(xcb-render) >= 0.9.92
$

Тут более интересная картина.  Зависимость на pkgconfig(pixman-1)
удалилась, а сходной зависимости на libpixman-devel не появилось - т.е.
pixman указан только в Requires.private, а в хедерах нигде не включается.
Т.е. pixman является настоящей private зависимостью, которой и не должно
быть в libcairo-devel.  Обращает на себя зависимость pkgconfig(libpng) -
сходной зависимости на libpng-devel не появилось.  Это, скорее всего,
означает, что pkgconfig зависимость ошибочно указана в Requires, тогда как
должна быть указана в Requires.private.

В связи с этими изменениями я пересоберу некоторые пакеты.

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Damir Shayhutdinov]

> Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
> 1) Оставлять в зависимостях только Requires, а Requires.private убрать.
> 2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры
> включаются, чтобы появились дополнительные зависимости на *-devel
> пакеты с хедерами.  Скрипт cpp.req был написан почти три года назад,
> но в нём не было необходимости, т.к. pkgconfig.req давал неплохой
> результат.  Никогда не знаешь, чего придётся доставать из штанин.

Дядя Лёша, вопрос из зала - а как же быть с условными зависимостями?

#ifdef USE_FOO_H

#include <foo.h>

#endif

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On Sun, Feb 27, 2011 at 07:45:50PM +0300, Damir Shayhutdinov wrote:
> > Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
> > 1) Оставлять в зависимостях только Requires, а Requires.private убрать.
> > 2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры
> > включаются, чтобы появились дополнительные зависимости на *-devel
> > пакеты с хедерами.  Скрипт cpp.req был написан почти три года назад,
> > но в нём не было необходимости, т.к. pkgconfig.req давал неплохой
> > результат.  Никогда не знаешь, чего придётся доставать из штанин.
> 
> Дядя Лёша, вопрос из зала - а как же быть с условными зависимостями?
> 
> #ifdef USE_FOO_H
> 
> #include <foo.h>
> 
> #endif

Просьба уточнить, каким образом включается -DUSE_FOO_H.
Если автоматически, например, из другого заголовка в этом пакете,
или из pkg-config --cflags согласно .pc-файлу в этом пакете, то и
зависимость, с высокой вероятностью, подцепится автоматически.
А если вручную, то и зависимость можно прописать вручную.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Alexey Tourbin]

On Sun, Feb 27, 2011 at 07:45:50PM +0300, Damir Shayhutdinov wrote:
> > Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
> > 1) Оставлять в зависимостях только Requires, а Requires.private убрать.
> > 2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры
> > включаются, чтобы появились дополнительные зависимости на *-devel
> > пакеты с хедерами.  Скрипт cpp.req был написан почти три года назад,
> > но в нём не было необходимости, т.к. pkgconfig.req давал неплохой
> > результат.  Никогда не знаешь, чего придётся доставать из штанин.
> 
> Дядя Лёша, вопрос из зала - а как же быть с условными зависимостями?

Учитываются только те файлы, которые реально включаются.
Именно поэтому используется реальный /usr/bin/cpp.
Идея реализации примерно такая:

$ cpp `pkg-config --cflags xft` /usr/include/X11/Xft/Xft.h |grep ^# |head
# 1 "/usr/include/X11/Xft/Xft.h"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/X11/Xft/Xft.h"
# 38 "/usr/include/X11/Xft/Xft.h"
# 1 "/usr/lib64/gcc/x86_64-alt-linux/4.5.1/include/stdarg.h" 1 3 4
# 40 "/usr/lib64/gcc/x86_64-alt-linux/4.5.1/include/stdarg.h" 3 4
# 102 "/usr/lib64/gcc/x86_64-alt-linux/4.5.1/include/stdarg.h" 3 4
# 39 "/usr/include/X11/Xft/Xft.h" 2
# 1 "/usr/include/ft2build.h" 1 3 4

Здесь показан стек включаемых файлов (см. info cpp "Preprocessor Output").
Соответственно, нам надо взять взять файлы на первом фрейме стека - это
и будут реально включаемые файлы.

> #ifdef USE_FOO_H
> 
> #include <foo.h>
> 
> #endif

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Damir Shayhutdinov]

>> Дядя Лёша, вопрос из зала - а как же быть с условными зависимостями?
>>
>> #ifdef USE_FOO_H
>>
>> #include <foo.h>
>>
>> #endif
>
> Просьба уточнить, каким образом включается -DUSE_FOO_H.
> Если автоматически, например, из другого заголовка в этом пакете,
> или из pkg-config --cflags согласно .pc-файлу в этом пакете, то и
> зависимость, с высокой вероятностью, подцепится автоматически.
> А если вручную, то и зависимость можно прописать вручную.

Ага, вот про использование pkg-config --cflags в исходном письме было
не понятно. А вообще это изменение применимо только к пакетам,
заточенным под pkgconfig?

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On Mon, Feb 28, 2011 at 12:35:56PM +0300, Damir Shayhutdinov wrote:
> >> Дядя Лёша, вопрос из зала - а как же быть с условными зависимостями?
> >>
> >> #ifdef USE_FOO_H
> >>
> >> #include <foo.h>
> >>
> >> #endif
> >
> > Просьба уточнить, каким образом включается -DUSE_FOO_H.
> > Если автоматически, например, из другого заголовка в этом пакете,
> > или из pkg-config --cflags согласно .pc-файлу в этом пакете, то и
> > зависимость, с высокой вероятностью, подцепится автоматически.
> > А если вручную, то и зависимость можно прописать вручную.
> 
> Ага, вот про использование pkg-config --cflags в исходном письме было
> не понятно. А вообще это изменение применимо только к пакетам,
> заточенным под pkgconfig?

Нет, отчего же.  К сожалению, если у библиотеки CFLAGS формируются с
помощью %_bindir/*-config, то они в cpp.req не подхватятся.  Правда, таких
библиотек осталось немного.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Yuri N. Sedunov]

В Вск, 27/02/2011 в 17:38 +0300, Alexey Tourbin пишет:
> Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
> 1) Оставлять в зависимостях только Requires, а Requires.private убрать.
> 2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры

Надуло:
$ rpmq -R libgtk3vnc-devel
libgtk3vnc = 0.4.3-alt2
libgvnc-devel = 0.4.3-alt2
/usr/include/gtk-vnc-1.0/vncgrabsequence.h  
libgtk+2-devel  
pkgconfig(gtk+-3.0) >= 3.0.0

-- 
Yuri N. Sedunov

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Wed, Mar 02, 2011 at 08:50:34AM +0300, Yuri N. Sedunov wrote:
> В Вск, 27/02/2011 в 17:38 +0300, Alexey Tourbin пишет:
> > Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
> > 1) Оставлять в зависимостях только Requires, а Requires.private убрать.
> > 2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры
> 
> Надуло:
> $ rpmq -R libgtk3vnc-devel
> libgtk3vnc = 0.4.3-alt2
> libgvnc-devel = 0.4.3-alt2
> /usr/include/gtk-vnc-1.0/vncgrabsequence.h  

А почему этот .h не соптимизировался совсем?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Alexey Tourbin]

On Wed, Mar 02, 2011 at 08:50:34AM +0300, Yuri N. Sedunov wrote:
> В Вск, 27/02/2011 в 17:38 +0300, Alexey Tourbin пишет:
> > Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
> > 1) Оставлять в зависимостях только Requires, а Requires.private убрать.
> > 2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры
> 
> Надуло:
> $ rpmq -R libgtk3vnc-devel
> libgtk3vnc = 0.4.3-alt2
> libgvnc-devel = 0.4.3-alt2
> /usr/include/gtk-vnc-1.0/vncgrabsequence.h  
> libgtk+2-devel  
> pkgconfig(gtk+-3.0) >= 3.0.0

Появилась неправильная зависимость на libgtk+2-devel?
Тут непросто автоматически выбрать между libgtk+2-devel и libgtk+3-devel.
Для получения cflags выполняется pkg-config %buildroot%_pkgconfigdir/*.pc,
шелл сортирует глоб, и по-видимому в cflags сначала идут флаги для gtk2,
а потом уже для gtk3.  Этот случай можно исправить, если сначала
обрабатывать запакованные .pc, а потом уже все остальные .pc в билруде
по глобу (чтобы сначала шли "запакованные" cflags).  Попробую сделать.

Заметил ещё что зависимость на libgtk+3-devel появится в
libavahi-ui-common-devel, не знаю правильно это или нет.
http://git.altlinux.org/beehive/logs/Sisyphus-x86_64/latest/success/avahi-0.6.28-alt6

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Yuri N. Sedunov]

В Срд, 02/03/2011 в 16:43 +0300, Alexey Tourbin пишет:
> On Wed, Mar 02, 2011 at 08:50:34AM +0300, Yuri N. Sedunov wrote:
> > В Вск, 27/02/2011 в 17:38 +0300, Alexey Tourbin пишет:
> > > Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
> > > 1) Оставлять в зависимостях только Requires, а Requires.private убрать.
> > > 2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры
> > 
> > Надуло:
> > $ rpmq -R libgtk3vnc-devel
> > libgtk3vnc = 0.4.3-alt2
> > libgvnc-devel = 0.4.3-alt2
> > /usr/include/gtk-vnc-1.0/vncgrabsequence.h  
> > libgtk+2-devel  
> > pkgconfig(gtk+-3.0) >= 3.0.0
> 
> Появилась неправильная зависимость на libgtk+2-devel?
Да.

> Тут непросто автоматически выбрать между libgtk+2-devel и libgtk+3-devel.
> Для получения cflags выполняется pkg-config %buildroot%_pkgconfigdir/*.pc,
> шелл сортирует глоб, и по-видимому в cflags сначала идут флаги для gtk2,
> а потом уже для gtk3.  Этот случай можно исправить, если сначала
> обрабатывать запакованные .pc, а потом уже все остальные .pc в билруде
> по глобу (чтобы сначала шли "запакованные" cflags).  Попробую сделать.
> 
> Заметил ещё что зависимость на libgtk+3-devel появится в
> libavahi-ui-common-devel, не знаю правильно это или нет.

Нет, не правильно.

-- 
Yuri N. Sedunov

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Alexey Tourbin]

On Wed, Mar 02, 2011 at 12:10:58PM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 02, 2011 at 08:50:34AM +0300, Yuri N. Sedunov wrote:
> > В Вск, 27/02/2011 в 17:38 +0300, Alexey Tourbin пишет:
> > > Новый план выхода из кризиса (реализован в 4.0.4-alt100.22):
> > > 1) Оставлять в зависимостях только Requires, а Requires.private убрать.
> > > 2) Продувать хедеры через /usr/bin/cpp и смотреть, какие ещё хедеры
> > 
> > Надуло:
> > $ rpmq -R libgtk3vnc-devel
> > libgtk3vnc = 0.4.3-alt2
> > libgvnc-devel = 0.4.3-alt2
> > /usr/include/gtk-vnc-1.0/vncgrabsequence.h  
> 
> А почему этот .h не соптимизировался совсем?

При сборке rpm говорит:
warning: libgtk3vnc-devel: non-strict dependency on libgtkvnc-devel

Этот хедер и даёт non-strict dependency on libgtkvnc-devel,
которая не может быть соптимизирована.

Видимо, это продолжение обсуждаемой ошибки: при более правильных
cflags должен был подцепиться хедер
/usr/include/gtk-vnc-2.0/vncgrabsequence.h
который запакован в самом пакете.

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Alexey Tourbin]

On Sun, Feb 27, 2011 at 08:17:27PM +0300, Alexey Tourbin wrote:
> $ cpp `pkg-config --cflags xft` /usr/include/X11/Xft/Xft.h |grep ^# |head
> # 1 "/usr/include/X11/Xft/Xft.h"
> # 1 "<built-in>"
> # 1 "<command-line>"
> # 1 "/usr/include/X11/Xft/Xft.h"
> # 38 "/usr/include/X11/Xft/Xft.h"
> # 1 "/usr/lib64/gcc/x86_64-alt-linux/4.5.1/include/stdarg.h" 1 3 4
> # 40 "/usr/lib64/gcc/x86_64-alt-linux/4.5.1/include/stdarg.h" 3 4
> # 102 "/usr/lib64/gcc/x86_64-alt-linux/4.5.1/include/stdarg.h" 3 4
> # 39 "/usr/include/X11/Xft/Xft.h" 2
> # 1 "/usr/include/ft2build.h" 1 3 4
> 
> Здесь показан стек включаемых файлов (см. info cpp "Preprocessor Output").
> Соответственно, нам надо взять взять файлы на первом фрейме стека - это
> и будут реально включаемые файлы.

Обнаружил интересную особенность: если файл уже включен, то он может
не появиться на первом фрейме стека (в выводе cpp).  Напр.

/usr/lib64/R/library/Matrix/include/Matrix.h
     3  #include <Rdefines.h>
     4  #include <Rconfig.h>
     5  #include "cholmod.h"

cpp.req обнаружит только зависимость на Rdefines.h, т.к. Rdefines.h
в свою очередь включает Rconfig.h.  При повторном включении Rconfig.h
даёт пустой вывод, и препроцессор его не аннотирует.

Что в принципе не очень хорошо.  Но я не знаю другого способа вклиниться
в cpp, и судя по cpp(1) такого способа скорее всего просто нет.  Проверил
cpp -H, он обладает таким же дефектом.

$ cpp -I/usr/include/R -H /usr/lib64/R/library/Matrix/include/Matrix.h 2>&1 >/dev/null |grep /R/
. /usr/include/R/Rdefines.h
.. /usr/include/R/R_ext/Memory.h
.. /usr/include/R/R_ext/RS.h
... /usr/include/R/Rconfig.h
... /usr/include/R/R_ext/Error.h
.. /usr/include/R/Rinternals.h
... /usr/include/R/R_ext/Arith.h
.... /usr/include/R/R_ext/libextern.h
... /usr/include/R/R_ext/Boolean.h
... /usr/include/R/R_ext/Complex.h
... /usr/include/R/R_ext/PrtUtil.h
.... /usr/include/R/R_ext/Print.h
... /usr/include/R/R_ext/Utils.h
... /usr/include/R/R_ext/libextern.h
. /usr/lib64/R/library/Matrix/include/cholmod.h
$

Re: [devel] pkg-config Requires.private - полчища саранчи и враги народа

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

On Thu, Mar 03, 2011 at 02:29:38AM +0300, Alexey Tourbin wrote:
[...]
> Обнаружил интересную особенность: если файл уже включен, то он может
> не появиться на первом фрейме стека (в выводе cpp).  Напр.
> 
> /usr/lib64/R/library/Matrix/include/Matrix.h
>      3  #include <Rdefines.h>
>      4  #include <Rconfig.h>
>      5  #include "cholmod.h"
> 
> cpp.req обнаружит только зависимость на Rdefines.h, т.к. Rdefines.h
> в свою очередь включает Rconfig.h.  При повторном включении Rconfig.h
> даёт пустой вывод, и препроцессор его не аннотирует.
> 
> Что в принципе не очень хорошо.  Но я не знаю другого способа вклиниться
> в cpp, и судя по cpp(1) такого способа скорее всего просто нет.  Проверил
> cpp -H, он обладает таким же дефектом.
> 
> $ cpp -I/usr/include/R -H /usr/lib64/R/library/Matrix/include/Matrix.h 2>&1 >/dev/null |grep /R/
> . /usr/include/R/Rdefines.h
> .. /usr/include/R/R_ext/Memory.h
> .. /usr/include/R/R_ext/RS.h
> ... /usr/include/R/Rconfig.h

Можно сделать вывод, что ограничиваться первым фреймом недостаточно.
Видимо, надежнее будет останавливаться на первых файлах за пределами
%buildroot.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] cpp.req

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

On Mon, Feb 28, 2011 at 03:30:59PM +0300, Dmitry V. Levin wrote:
> Нет, отчего же.  К сожалению, если у библиотеки CFLAGS формируются с
> помощью %_bindir/*-config, то они в cpp.req не подхватятся.  Правда, таких
> библиотек осталось немного.

Вот реальный пример: правильный gpgme.pc отсутствует, и cpp.req не справляется:
http://git.altlinux.org/tasks/39999/build/100/i586/log

/usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h:89:2: error: #error GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" in the GPGME manual.
cpp.req: /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h: cpp failed, trying c++ mode
/usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h:89:2: error: #error GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" in the GPGME manual.
cpp.req: WARNING: /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h: cpp failed

Впрочем, gpgme-config --cflags тоже не помог бы.

P.S. Зависимости у libgpgme-devel-1.3.0-alt5.i586.rpm и все равно
получились одинаковые.  Повезло.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] cpp.req

[Alexey Tourbin]

On Tue, Mar 08, 2011 at 07:47:43PM +0300, Dmitry V. Levin wrote:
> On Mon, Feb 28, 2011 at 03:30:59PM +0300, Dmitry V. Levin wrote:
> > Нет, отчего же.  К сожалению, если у библиотеки CFLAGS формируются с
> > помощью %_bindir/*-config, то они в cpp.req не подхватятся.  Правда, таких
> > библиотек осталось немного.
> 
> Вот реальный пример: правильный gpgme.pc отсутствует, и cpp.req не справляется:
> http://git.altlinux.org/tasks/39999/build/100/i586/log
> 
> /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h:89:2: error: #error GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" in the GPGME manual.
> cpp.req: /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h: cpp failed, trying c++ mode
> /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h:89:2: error: #error GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section "Largefile support (LFS)" in the GPGME manual.
> cpp.req: WARNING: /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h: cpp failed
> 
> Впрочем, gpgme-config --cflags тоже не помог бы.
> 
> P.S. Зависимости у libgpgme-devel-1.3.0-alt5.i586.rpm и все равно
> получились одинаковые.  Повезло.

Зависимости получились одинаковые, потому что в пакете libgpgme-devel
вручную уже добавлена зависимость на libgpg-error-devel.  Если бы cpp.req
отрабтал правильно, то зависимость можно было бы не добавлять/ удалить уже
добавленную зависимость.

Есть пакеты, в которых неправильно указаны такого рода *-devel
зависимости.  Например, в пакете libqt4-devel есть зависимость на xorg-devel,
тогда как cpp.req генерирует "нормальную" зависимость только на libGL-devel,
да и то это требуется только для поддержки OpenGL.  То есть зависимость на
xorg-devel ничем не обоснована, кроме фантазии мейнтейнера.

Я исправил некоторые пакеты с такими зависимостями, но не все. Во-первых,
не все мейнтейнеры довольны, когда я пересобираю их пакеты, и не хотелось
бы создавать лишних конфликтов по такой простой причине.  Во-вторых,
воротилы от бизнеса форсируют создание нового "стабильного" бранча для
Национальной ОС.  Если убрать в libqt4-devel зависимость на xorg-devel,
то сборка каких-то пакетов может сломаться из-за недостаточных зависимостей,
что вызовет неудовольствие воротил от бизнеса, и они не подпустят к распилу
государственных средств.  Что конечно тоже нежелательно, тем более по
такой простой причине.  Получается, лучше всего самоустраниться из этого
процесса.-(

Случай с gpgme.h показывает, что не только cpp.req не справляется
(например, по причине отсуствия нужных флагов -I/dir, как в некоторых
других случаях), но и сам этот хедер не поддается включению в дефолтной
конфигурации.  Можно было бы попытаться каким-нибудь хитрым способом
заменить #error на #warning.  С другой стороны, существуют "частные"
конфугации, не предназначенные для включения (например, файлы с winsock2.h
исправлять не нужно, т.к. они предназначены для ненациональной ОС).
Так что я думаю, что логику cpp.req нужно оставить прежней - анализировать
завсимости только тех хедеров, которые удается "полностью" включить.

С *-config файлами есть принципиальная проблема, которая препятствует их
использованию в cpp.req: они предполагают, что всё ихнее добро уже
установлено в хост-систему.  Я помню (ещё три года назад это было),
что в пакете wxGTK выполнялись какие-то файлтесты для libs, типа
[ -f ${libdir}/... ].  Всё это не слишком тривиально адаптируется
к RPM_BUILD_ROOT.  Так что нежелание использовать *-config тоже
сознательное.

Re: [devel] cpp.req

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 797 bytes --]

On Tuesday 08 March 2011 19:47, Dmitry V. Levin wrote:
> On Mon, Feb 28, 2011 at 03:30:59PM +0300, Dmitry V. Levin wrote:
> > Нет, отчего же.  К сожалению, если у библиотеки CFLAGS формируются с
> > помощью %_bindir/*-config, то они в cpp.req не подхватятся.  Правда,
> > таких библиотек осталось немного.
> 
> Вот реальный пример: правильный gpgme.pc отсутствует, и cpp.req не
> справляется: http://git.altlinux.org/tasks/39999/build/100/i586/log
> 
> /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h:89:2: error: #error GPGME
> was compiled with _FILE_OFFSET_BITS = 64, please see the section
> "Largefile support (LFS)" in the GPGME manual
Я по руководству так понял, что пользователь файла gpgme.h должен что-либо 
делать.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] cpp.req

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

On Wed, Mar 09, 2011 at 02:42:28PM +0300, Sergey V Turchin wrote:
> On Tuesday 08 March 2011 19:47, Dmitry V. Levin wrote:
> > On Mon, Feb 28, 2011 at 03:30:59PM +0300, Dmitry V. Levin wrote:
> > > Нет, отчего же.  К сожалению, если у библиотеки CFLAGS формируются с
> > > помощью %_bindir/*-config, то они в cpp.req не подхватятся.  Правда,
> > > таких библиотек осталось немного.
> > 
> > Вот реальный пример: правильный gpgme.pc отсутствует, и cpp.req не
> > справляется: http://git.altlinux.org/tasks/39999/build/100/i586/log
> > 
> > /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h:89:2: error: #error GPGME
> > was compiled with _FILE_OFFSET_BITS = 64, please see the section
> > "Largefile support (LFS)" in the GPGME manual
> Я по руководству так понял, что пользователь файла gpgme.h должен что-либо 
> делать.

Только обычно такие действия сразу закладывают в pkg-config --cflags, а
здесь авторы библиотеки решили отличиться и отправили пользователя читать
документацию.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] cpp.req

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 768 bytes --]

On Wednesday 09 March 2011 15:46, Dmitry V. Levin wrote:

[...]
> > > /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h:89:2: error: #error
> > > GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section
> > > "Largefile support (LFS)" in the GPGME manual
> > 
> > Я по руководству так понял, что пользователь файла gpgme.h должен
> > что-либо делать.
> 
> Только обычно такие действия сразу закладывают в pkg-config --cflags, а
> здесь авторы библиотеки решили отличиться и отправили пользователя читать
> документацию.
Ну да. Я хоть и прочел, толку мало :-)
Что мне делать? Заменить в gpgme.h это место на
#ifndef _FILE_OFFSET_BITS
#define _FILE_OFFSET_BITS 64
#endif
или вообще убрать его?

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] cpp.req

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Wed, Mar 09, 2011 at 04:13:07PM +0300, Sergey V Turchin wrote:
> On Wednesday 09 March 2011 15:46, Dmitry V. Levin wrote:
> 
> [...]
> > > > /usr/src/tmp/gpgme-buildroot/usr/include/gpgme.h:89:2: error: #error
> > > > GPGME was compiled with _FILE_OFFSET_BITS = 64, please see the section
> > > > "Largefile support (LFS)" in the GPGME manual
> > > 
> > > Я по руководству так понял, что пользователь файла gpgme.h должен
> > > что-либо делать.
> > 
> > Только обычно такие действия сразу закладывают в pkg-config --cflags, а
> > здесь авторы библиотеки решили отличиться и отправили пользователя читать
> > документацию.
> Ну да. Я хоть и прочел, толку мало :-)
> Что мне делать? Заменить в gpgme.h это место на
> #ifndef _FILE_OFFSET_BITS
> #define _FILE_OFFSET_BITS 64
> #endif
> или вообще убрать его?

Ничего тебе с gpgme.h делать не надо, все пользователи gpgme.h уже все сделали. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] cpp.req

[Michael Shigorin]

On Wed, Mar 09, 2011 at 04:16:58PM +0300, Dmitry V. Levin wrote:
> Ничего тебе с gpgme.h делать не надо, все пользователи gpgme.h
> уже все сделали. :)

А мне с SimGear что-то надо делать?

find-requires: running scripts (cpp,debuginfo,files,lib,pam,perl,pkgconfig,pkgconfiglib,python,rpmlib,shebang,shell,static,symlinks)
/usr/src/tmp/SimGear-buildroot/usr/include/simgear/constants.h:34:17: fatal error: cmath: No such file or directory
compilation terminated.
cpp.req: /usr/src/tmp/SimGear-buildroot/usr/include/simgear/constants.h: cpp failed, trying c++ mode
Provides: SimGear = 2.0.0, SimGear-devel = 2.0.0
Requires: libOpenSceneGraph-devel, glibc-devel-static, libGL-devel, libX11-devel, plib-devel
[...]

(пакет собрался, он действительно boost'овый)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] cpp.req

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

On Thu, Mar 10, 2011 at 10:47:46AM +0200, Michael Shigorin wrote:
> On Wed, Mar 09, 2011 at 04:16:58PM +0300, Dmitry V. Levin wrote:
> > Ничего тебе с gpgme.h делать не надо, все пользователи gpgme.h
> > уже все сделали. :)
> 
> А мне с SimGear что-то надо делать?
> 
> find-requires: running scripts (cpp,debuginfo,files,lib,pam,perl,pkgconfig,pkgconfiglib,python,rpmlib,shebang,shell,static,symlinks)
> /usr/src/tmp/SimGear-buildroot/usr/include/simgear/constants.h:34:17: fatal error: cmath: No such file or directory
> compilation terminated.
> cpp.req: /usr/src/tmp/SimGear-buildroot/usr/include/simgear/constants.h: cpp failed, trying c++ mode
> Provides: SimGear = 2.0.0, SimGear-devel = 2.0.0
> Requires: libOpenSceneGraph-devel, glibc-devel-static, libGL-devel, libX11-devel, plib-devel
> [...]
> 
> (пакет собрался, он действительно boost'овый)

Судя по вышепроцитированному, cpp.req справился.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]