[devel] Требования к модулям. was: Собираем Python-2.6

[Evgeny Sinelnikov <sin@altlinux.ru>]

16 июля 2009 г. 23:47 пользователь Kirill Maslinsky
(kirill@altlinux.org) написал:
> On Thu, Jul 16, 2009 at 10:40:48PM +0400, Evgeny Sinelnikov wrote:
>> Продолжаю начатый вопрос по пересборке питона. Итого 414 пакетов...
>>
>> Ну, это очень много, но... Для меня является проблемой, по времени, не
>> только пересборка и проверка этой пересборки, но и сам процесс
>> вытягивания и заливки нужных gears, а кое-где и archive.
>
> Евгений, Вы можете для простых мантейнеров нескольких питоньих модулей
> кратко по пунктам описать, какие действия такие мантейнеры должны
> предпринять со своими пакетами и какие цели при этом будут достигнуты?
>
> Причём поконкретнее: в спеках это заменить на то, добавить пакет в task#
> и т.п. Я уверен, что многие простые мантейнеры нескольких модулей
> смогут достаточно быстро отреагировать и сделать необходимое для своих
> модулей, заодно их улучшив.
>

Итак, этот вопрос требует отдельной темы.

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

Во-вторых, эту информацию стоит оформить, как draft Policy и начать
его утверждение.

Начнём с первого. Я перечислю только основное, что требуется
технически. То, что необходимо для текущего переезда на Python-2.6.
Цель этого письма в том, чтобы не пропустить какую-нибудь мелочь,
которая, на самом деле, вовсе и не мелочь... Если для текущей
пересборки это не важно, прошу отложить комментарии до момента
обсуждения нового Python Policy.

На основании последних редакций Python Policy я вижу следующие
формальные требования:
1) Все модули, требующие питон содержат зависимость вида:
BuildRequires: python-devel = %__python_version

2) Зависимость вида:
Requires: python = %__python_version
не требуется, потому что проставляется автоматически.

3) Зависимость вида
BuildRequires: python-dev
недопустима и должна быть искоренена.

Эти пункты, видимо, должен уметь проверять репокоп.

Есть несколько не ясных пунктов
1) Группы Development/Python/Modules не существует. Везде используется
Development/Python. Был ли/Есть ли сакральным смысл в новой группе?
Мне кажется, что нет... Вообще, мне кажется, что групп у нас мало и
чего-то не хватает, но тематического... В общем, это не важно....

2) Требуется ли всё-таки явное указание на зависимость вида:
BuildPreReq: rpm-build-python >= %__rpm_build_python_version
?
Мне кажется, что это излишнее требование. Чего мы лишаемся без
соблюдения этого пункта?

3) требуется ли необходимое использование макросов для указания зависимостей:
%py_provides
%py_requires
%py_dependencies
%py_package_requires
%py_package_provides
%py_package_dependencies

Не чревато ли это требование, частыми нарушениями из-за не очевидности
и замысловатости? Чего мы лишаемся без соблюдения этого пункта?

4) Нужен ли механизм пересборки под заданный питон:
rpmbuild -ba python-module-<ИМЯ>.spec --with python<MAJOR><MINOR
?
Какие из пунктов, для этого необходимы?
Пока, мне кажется, что совместно с girar-builder этот механизм не
применим, то есть он полезен только для ручной пересборки.

И ещё, на недавно организованной странице по пересборке питона:
http://www.altlinux.org/Python_2.6/Rebuild
есть такой абзац:

Еще есть некоторое количество пакетов, зависимость от питона для
которых не понятна: в build depends питон не стоит, однако бинарный
пакет зависит от питона:
gtk-doc
glib2
libgtk+2
xorg-xcbproto-devel

Пересборка, по крайней мере трёх из этих пакетов (кроме libgtk+2,
который я не проверял), проходит в хешере нормально, поскольку питон
вытягивается через косвенные зависимости или минимальную сборочную
среду в которую входит rpm-build-python, вытягивающий python-base.

Должны ли пакеты использующие python, но не являющиеся модулями, иметь
явную сборочную зависимость на версию питона? Я полагаю, что не
должны.

-- 
Sin (Sinelnikov Evgeny)