[devel] Py_LIMITED_API

[Daniel]

    Hi!

    rpm-build-python3 теперь умеет работать с Py_LIMITED_API:
    1. Появился волшебный макрос %set_python3_limited_api, который через
    %optflags выставляет Py_LIMITED_API в используемую версию python3.[1]

    2. Появился специальный brp-скрипт, который, проходя по $RPM_PYTHON3_PATH
    проверяет, какие Python3 символы использует python3 so-модуль и какой у него
    ABI-суффикс:
    2.1.1 Если ABI-суффикс .abi3 (то есть типа использует стабильное Python3
    API), а у самого зависимость на нестабильные символы, то brp-скрипт карает
    криком и падением (контролируется макросом
    %{relax,strict}_python3_verify_abi)
    2.1.2 Если ABI-суффикс .cpython3-.* (то есть он типа ABI-зависим от
    конкретного субмажора python3), а у самого зависимость только лишь на
    стабильные символы, то brp-скрипт извещает об этом явлении и переименовывает
    модуль в .abi3.so

    3. python3.req.py проверяет и требуемые от python3 символы so-модуля, и
    ABI-суффикс:
    3.1 Если символы стабильные, суффикс .abi3 или пустой, то зависимость
    генерируется на python3-ABI(%arch) (без суффикса .{субмажор})
    3.2 Если символов вообще нет, суффикс пустой, то зависимость вообще не
    генерируется
    3.3 Во всех остальных случаях генерируется та же зависимость, что и раньше

    Новые макросы:
    1. %_python3_verify_abi - контролирует реакцию brp-скрипта на несовпадение
    заявленной и реальной стабильности требуемых python3 символов
    1.1 %strict_python3_verify_abi - включает жесткую проверку (по умолчанию,
    уже включено)
    1.2 %relax_python3_verify_abi - облегчает эту проверку

    2. %_python3_modules_rename_path - контролирует пути, по которым brp-скрипт
    может переименовывать модули (по умолчанию, в site-packages):
    2.1 %none_python3_modules_rename - нигде нельзя переименовывать
    2.2 %all_python3_modules_rename - везде можно
    2.3 %add_python3_modules_rename_path() - добавляет путь, по которому можно
    переименовывать

    FAQ:
    1. Зачем нужен brp-скрипт?
       - С одной стороны, жестоко обманывать пользователей, ложно заявляя
         использование стабильных символов. С другой, если модуль использует
         лишь стабильные символы и у него .abi3 суффикс (мб, после
         переименования), то его не нужно пересобирать

    2. Зачем проверять символы в python3.req.py:
       - Безопасно ослабляя зависимости модулей, мы можем ослабить и зависимости
         пакета, возможно, уменьшая тем самым размер задания с бутстрапом новой
         субмажорной версией python3

    3. Можно ли еще в каких пакетах добиться зависимости лишь от стабильного
    C-API python3?
       - Да, как правило, upstream сам это делает, либо явно врубая
         Py_LIMITED_API средствами сборки, либо неявно просто используя
         ограниченный список символов. Но есть все тот же макрос
         %set_python3_limited_api. Проверяйте, собирается ли Ваш пакет с ним.
         Но будьте осторожны, так как возможно такое, что модуль НЕ соберется,
         но сборочная система это прожует и либо не сгенерит модуль, либо
         заменит его на код на голом python3. Так что ошибки не будет, тесты
         пройдут, а состав пакета изменится. Также макрос может
         не подействовать, как, например, в случае
         python3-module-logbook или python3-module-pycryptodome

    4. А можно везде поврубать Py_LIMITED_API и отрубить лишь в некоторых?
       - Нет. К сожалению, тех, в которых можно, меньше, чем тех, в которых
         нельзя

    5. Много ли пакетов, где brp-скрипт выдал ошибку на несоответствие реальной
    и заявленной стабильности требуемых от python3 символов в so-модуле?
       - Нет, мы нашли всего 1 (python3-module-yyjson). И там апстрим уже сидит
         с готовыми исправлениями.

    6. Часто ли приходится запрещать brp-скрипту переименование модулей?
       - Мы увидели необходимость лишь в одном случае[2], когда:
           + Оставались модули, которые требовали нестабильных символов,
           следовательно, зависимость пакета не облегчилась бы;
           + Требовалась явная модификация спека, поскольку в списке файлов
           модуль перечислялся со старым суффиксом (cpython3-*).
    7. А если модуль собирается с Py_LIMITED_API версии 3.X, а
    в sisyphus 3.X+1?
        - Все-таки попробуйте врубить %set_python3_limited_api,
          скорее всего, прокатит. В большинстве отловленных
          случаев проблема сводится к нехватке include-ов и мы
          это починили на стороне python3.

    Спасибо Ване (imz@) за соучастие во всем этом, включая ревью и идеи по
    дизайну. Также спасибо Грише (grenka@) за выявление ряда недочетов,
    а также Глебу (glebfm@) за обсуждения вот этого всего. 

    [1] -
    https://git.altlinux.org/gears/b/blueman.git?p=blueman.git;a=commitdiff;h=4fb56a7b612bc45ab48743beb6e750392ffb76e8
    [2] -
    https://git.altlinux.org/people/kotopesutility/packages/python3-module-pygobject3.git?p=python3-module-pygobject3.git;a=commitdiff;h=be71b30703929686b80a45822e7551835b1af603
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20260804/1277d769/attachment-0001.bin>