Bug 58008

Вижу что в pc.in есть желаемое, а в итоговом результате - нету.
Но у меня в пакете нет ничего специального для того, что бы чистить pc файлы. Думаю что виноват кто-то в rpmbuild:

Cleaning files in /usr/src/tmp/oniguruma-buildroot (auto)
mode of './usr/lib64/libonig.so.5.5.0' changed from 0755 (rwxr-xr-x) to 0644 (rw-r--r--)
Verifying and fixing files in /usr/src/tmp/oniguruma-buildroot (binconfig,pkgconfig,libtool,desktop,gnuconfig)
/usr/bin/onig-config:
61c61
<         show_includedir=-I/usr/include
---
>         show_includedir=
/usr/lib64/pkgconfig/oniguruma.pc: Cflags: '-I${includedir}' --> ''
/usr/lib64/pkgconfig/oniguruma.pc: Libs: '-L${libdir} -lonig' --> '-lonig'
Checking contents of files in /usr/src/tmp/oniguruma-buildroot/ (default)

$ rpm -qf /usr/lib/rpm/fixup-pkgconfig 
rpm-build-4.0.4.210-alt1.x86_64

Т.к. проблема видимо глобальная, то локальные хаки глобально ничего не изменят - чинить надо rpm-build или rust-код.

-I/usr/include не нужен и даже вреден.  Далее следует цитата из man gcc:

You can use -I to override a system header file, substituting your own version, since these directories are searched before the standard system header file directories.  However, you should not use this option to add directories that contain vendor-supplied system header files; use -isystem for that.

Дим, а насколько вообще реально то, что (при условии что все другие дистрибутивы не вычищают pc файлы) смена порядка поиска заголовков может привести к проблемам ?

Ведь чистка pc файлов рассчитана на то, что их будет использовать только gcc, а реальность оказалась такова, что есть и другие потребители и они совсем не готовы к тому, что у нас поведение меняется от апстримного.

(Ответ для Anton Farygin на комментарий #1)
> Вижу что в pc.in есть желаемое, а в итоговом результате - нету.
> Но у меня в пакете нет ничего специального для того, что бы чистить pc
> файлы. Думаю что виноват кто-то в rpmbuild:
...

У меня наоборот, не убраны, хотя хотелось бы:

$ cat /usr/lib64/pkgconfig/tdjson.pc
prefix=/usr

Name: tdjson
Description: Telegram Library - JSON interface (shared)
Version: 1.8.52

CFlags: -I"${prefix}/include"
Libs: -L"${prefix}/lib64" -ltdjson
Requires.private: tdjson_private


Видимо, потому что не использованы промежуточные переменные типа
libdir=/usr/lib64
includedir=/usr/include

При каких условиях pkg-config не возвращает -I/usr/include, а должен?

Если ошибка в pkg-config-rs, то, вроде бы, он и должен её фиксить.

Зачем у нас удаляется -I/usr/include из *.pc файлов не вполне понятно, ведь это ломает поддержку PKG_CONFIG_SYSROOT_DIR / PKG_CONFIG_SYSTEM_INCLUDE_PATH. pkg-config сам справляется с удалением -I/usr/include, но может раньше он этого не делал? Тогда это просто устарело, зачем делать за pkg-config его работу.

Код, который удаляет -I от 2002. Может его убрать?

Или оставить только кейс с /usr/local/include

                new_val=`printf %s "$new_val" |sed -e 's,\(^\| \+\)-I/usr\(/local\)\?/include\($\| \+\),\1\3,g'` || return 1
                        new_val=`printf %s "$new_val" |sed -e 's,\(^\| \+\)-I\${includedir}\($\| \+\),\1\2,g'` || return 1


хотя, лучше и его убрать, так как заменять просто не нужно, а паковать в /usr/local запрещено.

И оставить замену для -Wl,-rpath убрав -L

                new_val=`printf %s "$new_val" |sed -e 's#\(^\| \+\)\(-L\|-Wl,-rpath,\)/usr\(/local\)\?/'"$RPM_LIB"'\($\| \+\)#\1\4#g'` &&
                new_val=`printf %s "$new_val" |sed -e 's#\(^\| \+\)\(-L\|-Wl,-rpath,\)\('$RPM_BUILD_ROOT'\|'$RPM_BUILD_DIR'\|/usr/lib[^/]*/gcc-lib\)[^ ]*\($\| \+\)#\1\4#g'` ||
                        new_val=`printf %s "$new_val" |sed -e 's#\(^\| \+\)\(-L\|-Wl,-rpath,\)\${libdir}\($\| \+\)#\1\3#g'` || return 1

@ldv?

На мой взгляд, при обычном и правильном использовании pkg-config ничего не должно поменяться. Наладится использование PKG_CONFIG_SYSROOT_DIR / PKG_CONFIG_SYSTEM_INCLUDE_PATH (хотя очевидно, что никто этим не пользовался). Что-то поменяется если кто-то парсит *.pc files.

Вот тестовое/rfc задание https://git.altlinux.org/tasks/410162/