[devel] Q: is python-module-sphinx build-recursion OK?

[Ivan Zakharyaschev]

Здравствуйте!

Как говорилось, в пересборке python3 самое неудобное -- непонятные циклы 
зависимостей.

Я сейчас пытаюсь осуществить первый шаг озвученной схемы: по формальному 
переезду не связанных с libpython питоновских пакетов в независмое от 
точной версии python положение. (Идея, что они будут работать без заботы о 
порядке пересборки.)

И выявился очень неприятный на мой взгляд цикл (уже на этом 
noarch-этапе -- из-за переезда /usr/lib/python3.3/site-packages в 
/usr/lib/python3/site-packages). Суть такая:

python-module-sphinx для своей сборки устанвливает пакет 
python-module-sphinx и копирует оттуда (по фиксированному пути) к себе в 
сборочную директорию парочку *.inv-файлов (из себя самого, только 
предыдущего релиза).

%prep
%setup

cp %SOURCE4 sphinx/ext/

%if_with python3
rm -rf ../python3
cp -a . ../python3
%endif

install -p -m644 %SOURCE1 %SOURCE2 .
install -p -m644 %SOURCE1 %SOURCE3 ../python3

install -p -m644 %python_sitelibdir/%oname/objects.inv doc
install -p -m644 %python_sitelibdir/%oname/objects.inv tests

%if_with python3
install -p -m644 %python3_sitelibdir/%oname/objects.inv ../python3/doc
install -p -m644 %python3_sitelibdir/%oname/objects.inv ../python3/tests
%endif

(Понятно, почему это обнаружилось: благодаря тому, что %python3_sitelibdir 
поменялось.)

Мне кажется это плохим. (Скажем, компилятор себя компилирующий ещё куда ни 
шло -- в конце концов, в таком случае речь просто о компиляторе, 
подчиняющемся стандарту языка), но копировать какой-то генерат... Ведь нет 
никакой гарантии, что старый пакет имеет какое-то разумное отношение к 
новой версии.

Что вы думаете?

Можно реализовать сборку python-module-sphinx как-то правильнее?

(Для проверки сборки в новых условиях вполне подойдёт репо из задания 
160266, хоть там rpm-build-python3 неидеален.)

-- 
Best regards,
Ivan