Хочу дописать своё мнение о том, хороший это механизм или нет, что 
требуется доделать.

On Tue, 5 Apr 2016, Ivan Zakharyaschev wrote:

> On Fri, 1 Apr 2016, Ivan Zakharyaschev wrote:
>
>>  (Им же в verify_elf делается LD_PRELOAD, чтобы не засорять лог сборки
>>  несущественными сообщениями об undefined symbols. Для случая, когда
>>  такая библиотека кладётся в системные /usr/lib/, есть макрос
>>  %requires_python_ABI_for_files; пример -- пакет boost или
>>  python3-module-pygobject или python-module-pygobject3. Иначе пакет не
>>  пропустят.)
>
> Появился механизм для проверки всяких .so-плагинов на undefined symbols. 
> Можно пользоваться (например, видел краем глаза обилие саодельных проверок в 
> спеке apache). В качестве примера с помощью него реализована:
>
> 1. проверка всего внутри python*/site-packages/ (раньше были warnings)
> 2. а также макрос %requires_python3_ABI_for_files с явным указанием 
> интересных файлов.
>
> Принцип такой, что verify-elf понимает пары переменных окружения вида 
> RPM_LD_PRELOAD_xxxx и RPM_FILES_TO_LD_PRELOAD_xxxx (в случае одного из 
> питоноа в качестве идентификатора вместо xxxx выбрано python3, например).

В нынешнем состоянии это нехорошо вот чем.

Одна из прелестей успешного прохождения verify-elf (с unresolved=strict) в 
том, что наш автомат получается обучен тому, как загружать библиотеки и 
откуда взять все нужные символы. Это формальное знание можно использовать 
в lib.req, чтобы получить точные зависимости на множества требуемых 
символов. Принципиально этому ничего не мешает.

Например, в случае расставления настоящих RPATH/RUNPATH достигается и 
прохождение verify-elf без замечаний, и получение кучи правильных 
зависимостей, которых бы иначе не увидел автомат.

Но в случае с этим механизмом LD_PRELOAD для обработки "плагинов" первая 
часть реализована (verify-elf), а вторая-то в общем виде нет (lib.req).

Конечно, макрос %requires_python3_ABI_for_files делает костыль-зависимость 
(вместо зависимости на конкретную libpython3.so или /usr/bin/python3, 
которые одинаковое ABI им предоставляют). Так что в этом случае вторая 
часть решена, но костыльно (и неточно, без завсимости на множества 
символов, что было бы ещё лучше).

А в общем случае в нынешнем виде не очень хочется рекомендовать 
использовать этот механизм без реализации второй части, т.е. пользы от 
lib.req.

Я тогда это не так хорошо осознавал, что они должны идти для пользы рука 
об руку: verify-elf и lib.req, поэтому предлагал вторую часть всем 
по-своему дописывать:

> Поверх этого можно реализовывать нужные Вам макросы или задействовать 
> напрямую.
>
> Как предлагает glebfm@, чтобы ld-preload-ить программы, а не библиотеки, они 
> должны быть PIE.

Думаю, можно было бы связать их теснее, и для RPM_LD_PRELOAD_xxxx 
генерировать просто всегда жёсткую зависимость вида:

Requires: xxxx >= set:.......

Тогда останется мейнтейнерам пакетов с xxxx ещё обеспечить появление 
соответствующих:

Provides: xxxx = set:.......

-- 
Best regards,
Ivan