|
Краткое описание жизненного цикла питона в репозитории
Жизненный цикл с точки зрения мантейнеров :
- В любой момент времени существует единственный основной пакет
python - пакет с именем python;
- В день выхода новой минорной версии python (X.Y), делается форк:
новая версия собирается под именем python, тогда как старая -
под именем pythonXY-1;
Замечание 1: Более строго было бы использовать имя pythonX.Y-1,
но тут сложилась некая традиция, не уверен, что хорошая;
Замечание 2: Для тех, кто в танке: "-" - знак арифметической
операции, т.е. если (X,Y) == (2,4), то pythonXY-1 == python23;
- После выхода новой минорной версии, все мантейнеры уведомляются
о необходимости пересборки и тестирования модулей с новой
версией python;
- Если через некоторое время (например - 1 месяц) модуль не был
пересобран - он удаляется из репозитория (кажется, это
называется orphaned);
- Как и раньше, основной версией python в Sisyphus является
последняя пересобранная, старые версии лежат только для тестовых
целей и в дистрибутив, если таковой будет собираться на основе
Sisyphus, не входят;
- Как следствие п.5, все модули в Sisyphus будут собираться и
поставлятся только с последней версией;
- При необходимости, любой потребитель Sisyphus может пересобрать
модуль под старую версию python и самостоятельно использовать
ее. Новая схема сборки допускает такую возможность указанием
ключа --with pythonMN;
- Новая схема сборки допускает решение, при котором в дистрибутив
входят две и более версии языка python с некоторыми модулями,
пересобранными под несколько версий. Такое решение может быть
использованио исключительно в ситуации, когда один из
необходимых пакетов дистрибутива не может быть пересобран с
последней версией python (например, Zope, хотя до сих пор этого
удавалось избежать). В этом случае подлежат пересборке
модули, требуемые этим пакетом и не более того. Пересборка
модулей ведется так, что бы запуск rpm на пересборку
_безуказания каких-либо ключей порождал валидный пакет для
pythonMN, снабженный префиксом python-moduleMN;
Замечание 2: Текущая версия новых макросов не позволяет это
сделать, но я надеюсь, что Алексей что-либо придумает, в
крайнем случае возможен следующий хак: явно включать в
пересобираемый spec соотв. макрос;
Замечание 3: Такая пересборка может приводить к появлению в
репозитории нескольких почти идентнчных файлов src.rpm c
пакетами модулей для python разных версий. Хотя это может
показаться странным, необходжимо учитывать следующее
обстоятельство: форк есть форк. И если в момент форка некий
модуль test-u.v.w можно было пересобрать для обеих версий,
то модуль test-u.v.w+n, при достаточно большом n (в случае
некоторых модулей ~1), скорее всего, нет: новые фичи в питон
для того и вводятся, чбы их использовать, и примеров я могу
привести достаточно много;
Жизненный цикл с точки зрения потребителей :
- Потребитель регулярно издает команду :
apt-get upgrade (или dist-upgrade)
Потребитель, не делающий этого, очевидно, не является
потребителем Sisyphus и о нем в этом разделе речи не идет ;)
- Потребитель следит за тем, чбы апгрейд проходил нормально (т.е.
новые версии python и модулей к нему ставились), при этом
"любимые" модули не сносились;
- Если потребитель увидел что-то типа "python-X.Y.Z will be
upgraded, but python-module-IMPORTANT will be removed", то это
повод писать письма мантейнеру модуля IMPORTANT с просьбами его
пересобрать. Конфликты такого рода решаются в рамках стандартной
POLICY Alt Linux Team и не являются python-специфичными;
- Новая схема сборки модулей гарантирует (зависмостями)
невозмиожность установки модулей от старых версий python с его
новыми версиями (по крайней мере на уровне минорных версий,
нужно ли затрагивать сабминоры - вопрос открытый, выйдет
python2.3.4 - посмотрим);
Правила работы с пакетом python
Небольшая преамбула : эти правила написаны по мотивам прототипа пакета
под названием test. Кое-что изменилось (я не стал вводить модуль
python-strict и python-core), но я не уверен еще в валидности этих
изменений: не все работает нормально. Вполне возможно, что
python-strict & python-core будут возвращены; Состав пакета :
Я медленно, но верно, пилю питон на части. Новый пакет будет состоять
примерно из следующих частей :
- python, python-base
- минимальная установка питона, достаточная
для его работы, практически не содержит модулей;
- python-modules
- псевдопакет, содержащий зависимости на все
модули питон, рекомендованные к установке (не рекомендован,
в частности, пакет python-obsolete);
- python-obsolete
- пакет, содержащий фрагменты python, которые
объявлены устаревшими (например, rotor.py) или несекъюрными
(он же, в более ранее время);
- python-modules-*
- много модулей, реально каждый пакет содежит
большую группу модулей, относящихся к примерно-одной
тематике, над автоматической кластеризацией я сейчас
работаю;
- python-tools-*
- различные инструменты для и на python,
например python-tools-idle;
- python-devel
- то, что необходимо для разработки на python;
- python-info
- документация в формате info;
- python-doc
- документация в других форматах;
- python-weak
- python с облегченными зависимостями, допускающий
провести совместную установку со старой версий pythonX.Y
- tkinter
- это tkinter. Возможно, будет переименован в python-modules-tkinter;
Разделенние python-info & python-doc сложилось исторически и мбть будет
устранено. Цель распилки питона на отдельные модули - минимизировать установку
при решении конкретных задач. Существуют определенные проблемы, например, с
поиском (в т.ч. автоматическим) зависимостей. Работы над их решением ведутся,
до их решения пакет python будет содержать явную зависимость на пакет
python-modules, что будет приводить к установке всех необходимых пакетов. После
их решения - зависимости в ваши модули будут проставлены автоматически.
Правила работы с пакетом :
Чбы проиллюстрировать работу, просто приведу несколько команд:
- Установка старой версии :
apt-get install python22
- 1 Обновление ее до новой версии (старая версия будет снесена):
apt-get install python
- 2 Установка новой версии с сохранением старой (для тех кому
надо):
apt-get install python-weak
- 2.1 Удаление старой версии
apt-get install python
Обычные пользователи проводят систему через стадии 1, 2.1; Разработчики,
которым некоторое время могут быть реально нужны обе версии python,
проводят систему через стадии 1, 2.2, 2.2.1, понимая при этом, что на
стадии 2.2 система может оказаться не юзабельной, по причине некоректности
зависимостей: python-weak менее требователен к зависимостям, и, в частности,
допускает совместную установку с python старых версий.
Правила сборки и офрмления модуля для языка python
- Модуль для python собирается с префиксом python-module-;
- Модуль для одной из старых версий pythonX.Y собирается с префиксом
pythonX.Y-module-;
- Модуль должен содержать явно указанную зависимость на версию питон,
использованный при его сборке, такая зависимость вводится указанием
кляуз вида :
python = %__python_version
python-devel = %__python_version
(Здесь есть некоторые тонкости, которых не было при использовании
старой схемы, поэтому вопрос сейчас изучается, возможны изменения);
- В параметре GROUP спека должен быть указан Development/Python/Modules;
- Для сборки модуля рекомендуетсся использовать темплейт, предложенный
Алексеем Морозовым для модуля python-serial, но его использование не
обязательно. По крайней мере, пока. В модуле, собранном таким образом,
все необходимые параметры будут проставлены автоматически;
- Отключать повторную байт-компиляцию python не рекомендуется, так как
иначе скомпилированные модули могут выводить некорректную диагностику
ошибок (неверный путь к файлу), что крайне неудобно (посыпятся жалобы
вида "ваша програма упала в /home/vasya/petya.py, а такого файла вообще
нет"). Я это проверил (и диагностику, и жалобы);
- Пример спека включен в пакет rpm-build-python;
- Для нового модуля можно получить прототип стандартного спека отдав
команду:
python setup.py bdist-altrpm --spec-only,
разумеется, файл setup.py должен быть от этого модуля. Подробнее,
см. документацию на distutils и bdist_altrpm (в пакете rpm-build-python).
Использование стандартного спека (я сам не проверял, цитирую автора) :
- Сборка :
rpmbuild -ba pyserial.spec
На выходе будет python-pyserial-*.rpm, причем, бинарные rpm привязаны к
текущей (вероятно, 2.3) версии python.
- Сборка под конкретный питон:
rpmbuild -ba pyserial.spec --with pythonXY
на выходе будут получаться pythonXY-pyserial...rpm, (AO:
напомню, что использование такого варианта сборки пока
ориентировано на частное использование);
В данный момент, в качестве XY может использоваться 22, 23 и
(задел на будущее) 24.
Зависимости на пакеты с другими модулями python надо прописывать как
Requires: python%__python_package_version-
В текущем варианте, насколько известно, последующая пересборка pythonXY-что-то там
без ключа приведет к попытке сборки под "основной" питон. Это не самая большая
проблема, так как пока ключик --with ориентирован на домашнее использование.
|
