[devel] some python packaging problems on the example of aiohttp

[Ivan Zakharyaschev]

Пакет python-module-aiohttp демонстрирует некоторые текущие проблемы
разной степени серьёзности.

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

1. он перестал собираться из-за зависимости на эти objects.inv

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

Хочется переписать %prepare_sphinx в духе последних собранных коммитов
python-module-sphinx (чтоб лез в /usr/share/, а не
/usr/lib/python3.3/site-packages/sphinx/ за objects.inv -- это
облегчит и переезд на новую версию, когда меняется путь, но часть
пакетов ещё не пересобрана)

Убрать BuildReqs на objects.inv. (А на уровне репозитория в целях
ускорения массового перехода на новый python3 будут добавлены
obsoletes-provides, но почему бы не почистить этот spec сразу.)

2. имеет в BuildReqs самого себя.

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

Хочется проверить, можно ли избавиться.

3. dangerous packaging в виде нечистки ../python3/, в котором
происходит сборка

Несерьёзно, потому что у нас hasher, но без hasher приводит к
непредсказуемым эффектам.

Хочется почистить по крайней мере как в последних собранных коммитах
python-module-snowballstemmer.

4. -f убрать у cp и rm там, где наличие/отсутствие файлов (как того же
../python3/) значит, что всё пошло не так, как задумал maintainer.

(Последние собранные коммиты ipython такие.)

Хочется более предсказуемую обламывающуюся сборку иметь. Почему бы
заодно не почистить.

(Ср. облом при прикладывании патчей, когда исходники поменялись.)


Денис (nbr@), может быть, поправишь проверишь?

-- 
Best regards,
Ivan