Похоже, нескольких питонов в репозитарии никогда не будет (по крайней
мере на системном и хорошо юзабельном уровне).  Кроме того, даже когда
в репозитарии было два питона, программа сборки дополнительных
питоновских модулей в двух штуках под каждый питон никогда не была
реализована (даже частично).

В обозримом будущем планируется переход на питон 2.5.
В связи с этим дальше лелеять надежны насчёт двух питонов я не вижу
смысла.

В последнее время было решено много мелких проблем по части питона,
которые однако в целом кое-что упрощают и позволяют отказаться от ряда
хаков в связи со старым полиси.

Я предлагаю переходное полиси для питона.  Оно устремлено к переходу
на 2.5, но его можно использовать уже сейчас.  В двух словах это полиси
состоит в том, что никакого полиси в общем-то нет.  Питоновские пакеты
не считаются какими-то особенными и не требуют специального полиси.

Предлагаю делать следующее.

0) Установить python-dev 2.4.4-alt13 (залит в incoming,
скоро будет в сизифе).
1) Вычистить из python-module-*.spec всё что специфично
для старого полиси.  В частности, не использовать макрос
в %name.
2) Запустить buildreq, который должен проставить зависимость
на python-devel (и на что-то ещё).
3) Убрать все питоновские зависимости, проставленные вручную,
в частности, python = %__python_version.  Поиск зависимостей
был докручен до более юзабельного состояния, и все безусловные
(top-level) зависимости теперь проставляются как в модулях,
так и в скриптах.  Поэтому "жирная" зависимость на python
не нужна (в ряде случаев достаточно python-base).  Также нужно
попробовать вычистить все хаки типа %add_python_req_skip.
Неправильных питоновских анметов теперь в основном не будет.
4) Убедиться, что если модуль компилированный, то у пакета автоматически
появилась зависимость на libpython2.4.so.1.0.  (По этой причине как
минимум у компилированных модулей можно не выставлять зависимость на
версию питона, как того требовало старое полиси).

Короче, предложенное переходное полиси в основном сводится к тому,
чтобы почистить спек и запустить buildreq.  То есть мотивирующая идея
здесь состоит в том, что полиси вгоняется "вглубь" сборочной среды
и реализуется автоматически, а не на уровне дополнительных манипуляций
в spec-файле.  Правда, конструкция становится более жесткой.