Calculate-utils + python:3.13 + шаблоны. Как можно обойти баг?

День добрый!

Очередная проблема при обработке шаблонов, аналогичная Шаблоны. Как их отлаживать?. Теперь для app-emulation/libvirt

Если сделать ebuild /var/db/repos/gentoo/app-emulation/libvirt/libvirt-10.10.0-r1.ebuild install, то в начале build.log пишут:

Спойлер
 * Checking for suitable kernel configuration options ...
 [ ok ]
 * Checking whether python3_13 is suitable ...
 *   dev-lang/python:3.13 ...
 [ ok ]
 *   python_check_deps ...
 [ ok ]
 * Using python3.13 to build (via PYTHON_COMPAT iteration)

А в самом конце ebuild /var/db/repos/gentoo/app-emulation/libvirt/libvirt-10.10.0-r1.ebuild qmerge выдают такое:

Спойлер
--- replaced dir /etc/conf.d
--- replaced dir /etc
>>> Regenerating /etc/ld.so.cache...
>>> Original instance of package unmerged safely.
Traceback (most recent call last):
  File "/usr/sbin/cl-core", line 18, in <module>
    import calculate.core.core_main as core_main
ModuleNotFoundError: No module named 'calculate'
>>> app-emulation/libvirt-10.10.0-r1 merged.
>>> Regenerating /etc/ld.so.cache...

В 3.13м питоне, разумеется, никаких модулей calculate.* нет. В /etc/python-exec/python-exec.conf прописано: python3.12. И вот возникают два вопроса:

  1. а не баг ли это в =sys-apps/calculate-utils-3.7.7.11 ?
  2. можно ли как-то самостоятельно обойти эти грабли, и заставить работать шаблоны?

И да, в это раз шаблон заведомо правильный, т.к. в точности аналогичный шаблон для openrc прекрасно работает.

Спойлер
# Calculate mergepkg(sys-apps/openrc)!= path=/etc/runlevels/default name=netmount append=remove comment=#

# Calculate mergepkg(app-emulation/libvirt)!= path=/etc/libvirt/qemu/networks/autostart name=default.xml append=remove comment=#

Обойти баг можно, если при сборке пакета будет использоваться питон, который в системе по умолчанию. Для этого:

  1. можно использовать переменную EPYTHON для переопределения используемой реализации питона через /etc/portage/package.env на ту, что по умолчанию
  2. можно сделать питон 3.13 по умолчанию, если это возможно и он очень нужен
  3. можно удалить питон 3.13 из системы, если он не нужен или не используется

Утилиты собраны питоном 3.12, естественно, никаких модулей кальки для питона 3.13 - нет.

Это как раз понятно :slight_smile:

Не понятно, зачем утилиты (действительно, собранные под 3.12й питон) работают под 3.13м питоном. IMHO, конечно, но это косяк-с.

Ещё раз - утилиты сбраны питоном 3.12 - для их работы дефолтом должен быть 3.12.
Хочется поэкспериментировать с 3.13 - пересобирай утилиты небинарно с ним, но никто не даст гарантии их работоспособности.
Гента и обновление питона это боль - так всегда было.

У Вас всё правильно написано, кроме исходного посыла — это не я хочу, это указано в ебилде пакета. Причём ладно бареос, он всегда тильдой помечен, но =app-emulation/libvirt-10.10.0-r1 вполне себе стабильный пакет.

Не совсем понял посыл. При чём тут это до версии утилит кальки и их нелюбви к “неправильному” питону? Пофиг какой пакет, стабильный, нестабильный, да хоть и в хардмаске - утилитам от этого ни жарко, ни холодно, установкой занимается портаж, а утилиты потом применяют уже свои шаблоны.
Работа утилит никак не регулируется ебилдом.

Блин, Вы перед тем как писать, пробовали читать? :man_facepalming:

В /etc/python-exec/python-exec.conf прописано: python3.12.

Мне казалось, что это и есть указание “дефолтового” питона в системе. Я неправ?

Работа утилит никак не регулируется ебилдом.

Вся беда в том, что так должно быть, но по факту утилиты реагируют на то, что написано в ебилде. И это легко проверяется, если ебилд отредактировать и переподписать.

Не вижу смысла сприть, в случае с openrc - у кальки для него свои шаблоны, формат конфига у него отнюдь не xml. Укажи формат конфига xml для ливбирта и проверь. Утитилы никак не взаимодействуют с содержимым ебилда. Они работают как хук в портаже и меняют только конфиги.

Ещё раз попробую описать проблему, извините, будет многа букаф. :pensive:

В начале про то, как всё бывает хорошо.

Есть sys-apps/openrc, который создаёт симлинк /etc/runlevels/default/netmount. Мне он не нужен, и поэтому создаётся шаблон, удаляющий этот симлинк. Содержимое этого шаблона:

# Calculate mergepkg(sys-apps/openrc)!= path=/etc/runlevels/default name=netmount append=remove comment=#

Повторюсь, в случае с openrc всё хорошо, симлинк удаляется.

Теперь про “плохо”.

Есть app-emulation/libvirt, который при установке создаёт симлинк /etc/libvirt/qemu/networks/autostart/default.xml Мне этот симлинк, как и в ситуации выше, тоже не нужен, и поэтому создаётся шаблон, удаляющий уже этот симлинк. Содержимое шаблона:

# Calculate mergepkg(app-emulation/libvirt)!= path=/etc/libvirt/qemu/networks/autostart name=default.xml append=remove comment=#

Если сравнить приведённые шаблоны, видно, что — с точностью до замены имён пакетов и симлинков — это один и тот же шаблон. Т.е. он заведомо рабочий.

Если сделать emerge app-emulation/libvirt, то симлинк создётся, т.е. шаблон НЕ отрабатывает, но пакет ставится, и сообщений об ошибках не выдаётся.

Если сделать ebuild /....../libvirt-10.10.0-r1.ebuild install, а потом ebuild /....../libvirt-10.10.0-r1.ebuild qmerge, то в конце выдадут сообщения от утилит, что они сломались. В первом посте есть выхлоп.

Теперь следите за руками. Редактируем /var/db/repos/gentoo/app-emulation/libvirt/libvirt-10.10.0-r1.ebuild , в 13й строке меняем PYTHON_COMPAT=( python3_{10..13} ) на PYTHON_COMPAT=( python3_{10..12} ) и делаем:

ebuild ...... digest
ebuild ...... clean
ebuild ...... install
ebuild ...... qmerge

В результате получаем установленный пакет, с отработавшим шаблоном, т.к. симлинк исчезает! Разумеется, emerge app-emulation/libvirt в случае с отредактированным ебилдом тоже работает.

Самый важный и главный вывод из этой истории: утилиты реагируют на содержимое ебилда.

default.xml не симлинк.
Реакция не на содержиме ебилда, а на версию питона. Скрее всего, портаж, видя 13-ый пито использует именно его для всех последующих операций. Ещё раз повторю - сделать 12-ый дефолтным. Если так уж нужен “несистемный” питон для собственых нужд, то использовать pyenv в хомяке, хоть 1.0 можно использовать для своих проектов.

eselect python list
eselect python set python3.12

Проверить системную переменную портажа PYTHON_COMPAT, установить значение python3_12
Для проверки сделать все действия, которые привдили к ошибке с префиксом и без изменения ебилда

PYTHON_COMPAT="python3_12" emereg ...

А ещё лучше, удалить 13-ый.
Ещё раз: питон в генту это боль и от неё никак не избавишься.

Это симлинк:

ls -lh /etc/libvirt/qemu/networks/autostart/default.xml
lrwxrwxrwx 1 root root 14 мар 21 13:22 /etc/libvirt/qemu/networks/autostart/default.xml -> ../default.xml

Сам файл меня мало волнует, мне надо удалить симлинк из /…/autostart/

Да, я согласен, что реакция на версию питона. Только беда в том, что версия питона задаётся в ебилде!

eselect python list уже неск. лет как устаревший механизм управления питоном в генте, откройте для себя /etc/python-exec/python-exec.conf Специально сейчас поставил app-eselect/eselect-python, извольте видеть:

Спойлер
#✓/root                                                                                         
#algiz # eselect python list 
Available Python interpreters, in order of preference:
  [1]   python3.12
  [2]   python3.13 (fallback)
#✓/root                                                                                         
#algiz # eselect python set 1 
#✓/root                                                                                         
#algiz # eselect python list 
Available Python interpreters, in order of preference:
  [1]   python3.12
  [2]   python3.13 (fallback)
#✓/root                                                                                         
#algiz #

Прошу прощения, но вот тут я не понял, Вашу мысль. Согласно документации:

The PYTHON_COMPAT variable is used by all Python eclasses, and must be declared in all ebuilds before they are inherited. It specifies the list of Python implementations supported by the package.

Т.е. любой ебилд, который наследует от питоновых еклассов обязан явно указать значение этой переменной ДО операции наследования. Пруф Т.е. дефолта для этой переменной нет.

Он приходит по зависимостям. Удалить, сами понимаете…

Спойлер
#✓/root                                                                                         
#algiz # emerge --depclean -avt python:3.13 

Calculating dependencies... done!
  dev-lang/python-3.13.2 pulled in by:
    app-crypt/mit-krb5-1.21.3 requires dev-lang/python:3.13
    app-crypt/p11-kit-0.25.5 requires dev-lang/python:3.13
    app-emulation/libvirt-10.10.0-r1 requires dev-lang/python:3.13
    app-emulation/spice-0.15.2 requires dev-lang/python:3.13
    app-misc/ca-certificates-20240203.3.98 requires dev-lang/python:3.13
    app-text/iso-codes-4.17.0 requires dev-lang/python:3.13
    dev-build/ninja-1.12.1 requires dev-lang/python:3.13
    dev-libs/glib-2.80.5-r1 requires dev-lang/python:3.13[xml(+)]
    dev-libs/icu-76.1-r1 requires dev-lang/python:3.13
    dev-libs/jsoncpp-1.9.6-r2 requires dev-lang/python:3.13
    dev-libs/libevdev-1.13.3 requires dev-lang/python:3.13
    dev-libs/zziplib-0.13.78-r1 requires dev-lang/python:3.13[xml(+)]
    dev-util/intel_clc-24.3.4 requires dev-lang/python:3.13
    dev-util/spirv-tools-1.4.304.0 requires dev-lang/python:3.13[xml(+)]
    gnome-base/librsvg-2.58.5 requires dev-lang/python:3.13
    llvm-core/libclc-19.1.7 requires dev-lang/python:3.13
    llvm-core/llvm-19.1.7 requires dev-lang/python:3.13
    llvm-runtimes/compiler-rt-19.1.7 requires dev-lang/python:3.13
    llvm-runtimes/compiler-rt-sanitizers-19.1.7 requires dev-lang/python:3.13
    media-libs/fontconfig-2.15.0-r1 requires dev-lang/python:3.13
    media-libs/graphene-1.10.8-r1 requires dev-lang/python:3.13
    media-libs/harfbuzz-10.1.0 requires dev-lang/python:3.13
    media-libs/libaom-3.10.0 requires dev-lang/python:3.13
    media-libs/libepoxy-1.5.10-r3 requires dev-lang/python:3.13[xml(+)]
    media-libs/libglvnd-1.7.0 requires dev-lang/python:3.13
    media-libs/mesa-24.3.4-r1 requires dev-lang/python:3.13
    media-libs/opus-1.5.2 requires dev-lang/python:3.13
    net-libs/libpsl-0.21.5 requires dev-lang/python:3.13
    sys-libs/glibc-2.40-r8 requires dev-lang/python:3.13
    x11-libs/libdrm-2.4.124 requires dev-lang/python:3.13
    x11-libs/libxcb-1.17.0 requires dev-lang/python:3.13[xml(+)]
    x11-misc/xkeyboard-config-2.43 requires dev-lang/python:3.13

>>> No packages selected for removal by depclean
#X/root                                                                                         
#algiz #

Ну, не знаю, я на генте с 2004г, конкретно сейчас подо мной 68 гентовых систем, какой-то особой боли с питоном не заметил. Я им, правда, не пользуюсь :slight_smile: А то, что приходит по зависимостям, всегда получалось спокойно разрулить.

В calculate включена опция --jobs=4. Это перенаправляет все выходные данные сборки в журналы.
Отключить можно в /etc/portage/make.conf/custom, раскоментировав строчку #EMERGE_JOBS="--jobs=1", если Вам понадобится.

Должен отработать хоть с установкой из исходников, хоть с установкой бинарного без всякого редактирования, если в системе не установлен питон 3.13.
Если питон3.13 установлен, попробуйте установить пакет из исходников:

PYTHON_COMPAT_OVERRIDE="python3_12" emerge -av --usepkg-exclude app-emulation/libvirt app-emulation/libvirt

или

EPYTHON="python3.12" emerge -av --usepkg-exclude app-emulation/libvirt app-emulation/libvirt

Эти команды переопределят питон на 3.12. Обе должны отработать с применением шаблона и редактировать ничего не нужно. Предпочтительнее вторая команда.
С командой ebuild также, например:

EPYTHON="python3.12" ebuild ...

Это все касается пакетов, в ебилдах которых наследуется python-any-r1.

Не думаю, что при удалении питона3.13 все рухнет. Скорее всего тут пакеты, в ебилдах которых наследуется python-any-r1. Этот екласс вроде используется, когда питон нужен только при сборке пакета.