[devel] Re: A: Полиси ( я свел все воедино ) + FAQ

[Mikhail Zabaluev <mhz@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 14044 bytes --]

Hello Andrey,

On Sun, Feb 22, 2004 at 10:32:27PM +0300, Andrey Orlov wrote:
>
>         2.  В день выхода новой минорной версии python (X.Y), делается форк:
>             новая версия собирается под именем python, тогда как старая -
>             под именем pythonXY-1;

Что за "-1"? Почему не просто pythonXY версии X.Y.Z, как у людей?

>             Замечание 1: Более строго было бы использовать имя pythonX.Y-1,
>                 но тут сложилась некая традиция, не уверен, что хорошая;

Это какой-то ментальный блок, существующий со времён kernelXY,
а то и раньше.

-------------- лирическое отступление --------------------
Ещё раз, для всех, кого тянет придумать новый причудливый суффикс для
зашифровывания номера версии, чтобы никто не догадался: точку в имени
пакета использовать МОЖНО и желательно. Подчёркивание между собственно
именем и номером версии как частью имени использовать можно, но
нежелательно (дело эстетики, как в случае с libtool_1.x: без
подчёркивания становится трудночитабельно).
Дефис AKA минус в именах пакетов использовать НЕЛЬЗЯ, это грех перед
Богом, за который вас заставят 1000 лет пересобирать пакеты в чистилище.
----------------------------------------------------------

>         8.  Новая схема сборки допускает решение, при котором в дистрибутив
>             входят две и более версии языка python с некоторыми модулями,
>             пересобранными под несколько версий. Такое решение может быть
>             использованио исключительно в ситуации, когда один из
>             необходимых пакетов дистрибутива не может быть пересобран с
>             последней версией python (например, Zope, хотя до сих пор этого
>             удавалось избежать). В этом случае подлежат пересборке
>             модули, требуемые этим пакетом и не более того. Пересборка
>             модулей ведется так, что бы запуск rpm на пересборку
>             _без_указания_ каких-либо ключей порождал валидный пакет для
>             pythonMN, снабженный префиксом python-moduleMN;

Поддерживаю.

>             Замечание 3: Такая пересборка может приводить к появлению в
>                 репозитории нескольких почти идентнчных файлов src.rpm c
>                 пакетами модулей для python разных версий. Хотя это может
>                 показаться странным, необходжимо учитывать следующее
>                 обстоятельство: форк есть форк. И если в момент форка некий
>                 модуль test-u.v.w можно было пересобрать для обеих версий,
>                 то модуль test-u.v.w+n, при достаточно большом n (в случае
>                 некоторых модулей ~1), скорее всего, нет: новые фичи в питон
>                 для того и вводятся, чбы их использовать, и примеров я могу
>                 привести достаточно много;

Поддерживаю.

>         4.  Новая схема сборки модулей гарантирует (зависмостямb)
>             невозмиожность установки модулей от старых версий python с его
>             новыми версиями

По-моему, слишком жёсткое ограничение.
Нужно решить лишь такую задачу: если есть зависимость между модулями,
эта зависимость должна учитывать версию python ABI. Как этого можно
достичь, я писал.

>             (по крайней мере на уровне минорных версий,
>             нужно ли затрагивать сабминоры - вопрос открытый, выйдет
>             python2.3.4 - посмотрим);

Я думаю, можно полагаться на неявное обязательство разработчиков
Python не ломать ABI между микро-релизами.

>         Я медленно, но верно, пилю питон на части.

В этом процессе главное -- чувство меры ;)

>         Новый пакет будет состоять
>         примерно из следующих частей :
>         
>             python, python-base -- минимальная установка питона, достаточная
>                 для его работы, практически не содержит модулей;

Я правильно понял, что python это "панама", которая тянет python-base
и python-modules?

>             python-obsoletes -- пакет, содержащий фрагменты python, которые
>                 объявлены устаревшими (например, rotor.py) или несекъюрными
>                 (он же, в более ранее время);

s/obsoletes/obsolete/ -- чтоб было более понятно по-английски.

>             python-modules -- псевдопакет, содержащий зависимости на все
>                 модули питон, рекомендованные к установке (не рекомендован,
>                 в частности, пакет python-obsoletes);
>                 
>             python-modules-* -- много модулей, реально каждый пакет содежит
>                 большую группу модулей, относящихся к примерно-одной
>                 тематике, над автоматической кластеризацией я сейчас
>                 работаю;

Я против избыточной "кластеризации" bundled модулей примерно по тем же
причинам, по которым протестовал против отщепления модулей perl от
штатной сборки.

По крайней мере, такое правило должно соблюдаться: если пользователь ставит
apt-get install python python-doc
он вправе расчитывать на наличие всех модулей, о которых написано в
Library Reference (за исключением тех, что в -obsolete: шоб знал,
дурилка!).
Иначе у пользователя, непосвящённого в премудрости дистрибутива,
возникнет ощущение, что ему "недоложили".
Возможность установки python-base как интерпретатора без модулей
плюс подобранного вручную набора python-modules-* может быть полезна.
Просто не нужно подвергать этому всех пользователей.

Вдобавок, без автоматического определения зависимостей
возникнут проблемы у разработчиков, которым вместо одной зависимости
на python = %__python_version как на всю платформу придётся смотреть,
какие микропакеты реально нужны для работы.

>             python-tools-* -- различные инструменты для и на python,
>                 например python-tools-idle;

Это есть хорошо. Idle должен был отпочковаться.

>             python-weak -- python с облегченными зависимостями, допускающий
>                 провести совместную установку со старой версий pythonX.Y    

Я чую ненужную сложность.
При условии, что во всех модулях прописана зависимость на
python = %__python_version, установка legacy python при апгрейде
произойдёт автоматически, если это будет нужно. Если все модули
в системе обновляются на новый ABI в тот же присест, legacy python
не будет установлен. Отпустите python-weak в пространство
невоплощённых идей.
Вдогонку: если апгрейд модуля/приложения требует python = 2.3, почему
бы не иметь в дистрибутиве python23, который благополучно вытянется,
если он такое предоставляет? У нас уже организовано так несколько
семейств пакетов, стоит ли здесь изобретать велосипеды?

>             tkinter -- это tkinter. Возможно, будет переименован в python-modules-tkinter;                

Сделайте исключение. Слишком многие знают старика под этим именем.

>             2.2.1 Удаление старой версии
>             
>                 apt-get install pythno

Не уверен, что правильно понял.

>     4.  В параметре GROUP спека должен быть указан Development/Python/Modules;        

Что же тогда останется в Development/Python? :)
Присоединяюсь к уже высказанному мнению, что в новой группе нет нужды.

>             Зависимости на пакеты с другими модулями python надо прописывать как
> 
>                 Requires: python%__python_package_version-<anotherModule>

Хотелось бы здесь поиметь автоматику...

Hint от соразработчика perl.{req,prov}, поимевшего кучу головной боли с
синтаксисом Perl: в скриптах на Python, хвала ему и его разработчикам,
совпадение регулярного выражения ^(import|from) даёт стопроцентную
гарантию безусловного включения другого модуля. Имя модуля отделено от
найденного ключевого слова "символами пустоты" и состоит из ASCII
alphanumerics, знаков подчёркивания и точек, которые нужно заменить на
'/' для получения относительного пути к файлу модуля (без суффикса
.py) или каталогу с файлом __init__.py

>         6.  Симлинки на головные модули пакетов, устанавливаемых многократно
>             с специфичными версиями python должны управлятся посредством
>             alternatives, что позволяет избежать ситуации, с запуском
>             головного модуля с неправильным питоном (так как alterantaives
>             изменит симлинк на tool одновременно с изменением симлинка на
>             python, а кто запускает tool не из /usr/bin - тот,
>             предположительно, знает, что делает). Альтернативный
>             альтернативам вариант - изменение записи в
>             #! - представляется трудоемким (хотя оптимизировать, конечно,
>             можно) и излишним (альтернативы решают проблему);

Интересно, как вы этого добьётесь, если python и инструмент
устанавливаются раздельно и используют отдельные конфигурации
для alternatives (slave невозможен).

Тут опять хочется предложить $PYTHON_VERSION и wrapper'ы в пакете
-common по примеру autoconf и иже с ним. Так и idle можно обернуть,
и всё остальное.

>         7.  Именование пакетов: я не сталкивался, пока, с прикладными
>             пакетами, которые не входили бы в python (как например IDLE), но
>             требовали бы (от меня) возможности сборки с каждым из
>             альтернативных питонов.  Честно говоря, разводить зоопарк с Zope
>             для каждого питона - крайне неразумно. Я предполагаю возможность
>             появления необходимости сборки с одним из альтернативных питонов
>             (в случае с Zope избежать этого удавалось с некоторым
>             напряжением), но и в этом случае мы будем иметь дело только с
>             одним пакетом (правда, в этом случае в заголовке стартового
>             модуля потребуется-таки вписать путь к правильному питону). 
>             Поэтому какое-либо префиксирование кажется излишним.

Поддерживаю.

>         Поддерживаю полиси я, Андрей Орлов, мантейнер пакета python & Zope. 
>         Я же обладаю (наверно) каким-то решающим голосом. Почему я? Потому
>         что логично поручить это мантейнеру python. Будет другой мантейнер
>         python - видимо, он же будет рулить и полиси. Почему решающим? 
>         Потому что должен же кто-то выбрать из двух стогов сена один ;), а я
>         достаточно туп и ленив, чбы :
>         
>             a)  Не делать лишних шагов;
>         
>             b)  Не вдаватся в многочисленный тонкости: лучше
>                 удовлетворительное решение сегодня, чем замечательное -
>                 через год (тем более, что через год оно так и так будет);

IMHO, Ваше самоуничижение преувеличено ;)

>     Q9: Почему питонов много, а python-doc - один.
>     
>     A9: Черт его знает. До недавнего обращения мантейнера python-doc с
>         просьбой забрать пакет я об этом не задумывался, и на самом деле
>         было даже два python-doc
>         - второй в рамках python23 и под названием python23-info. Наверно,
>         держать доки под каждый python все-таки неразумно и python23-info
>         откочует в python-doc.

Поддерживаю. Однако, python-doc отяжелеет от всего многообразия форматов.

>     Q10: Одно время говорили о разрезании пакетов на подпакеты с модулями
>         py, pyo, pyc, что в этом направлении делается и на что это будет
>         похоже? И, кстати, когда это начнется?
>         
>     A10: Эксперименты ведутся уже сейчас, но это с собой несет столько
>         подводных камней, что не является частью настоящего перехода к новой
>         схеме питоновских модулей. Тем не менее некоторые вопросы могут быть
>         отвечены уже сейчас:
>         
>             1.  Всегда будет возможность установить файлы py, pyc и pyo, так
>                 как все они имеют свою, очень важную, область применимости.
>                 
>                 Замечание про файлы pyc & pyo:
>                 
>                     -   Установка только файлов py, pyc - при старте питон с
>                         ключом -O (работа с оптимизированными файлами
>                         байткода) будет приводить к перекомплиции, что
>                         непохоже на оптимальную работу;
>                         
>                     -   Установка только файлов py (выборочная), pyo - при
>                         старте без ключа -O имеющиеся в наличии файлы pyo
>                         будут игнорироваться, поэтому потребуется установко
>                         py для всех модулей, хотя имеет смысл только
>                         выборочная установка в целях отладки, в тоже время,
>                         при старте с ключом -O нормальная отладка
>                         невозможна;
>                         
>                     -   Установка только pyc - работа с ключом -O
>                         (оптимизированная) невозможна;
>                         
>                     -   Установка только py - перекомпиляция при каждом
>                         старте и серъезный объем на диске;
> 
>                 Чбы еще более напугать желающих неподумавши выбросить файлы
>                 pyc, добавлю: Zope, в норме, стартует два раза: рестарт
>                 делается при отсутствии отладочного режима с ключом -O.
>                 
>                 И, наконец, если кто не знает: "а еще их можно зиповать",
>                 фича новая (python23), непроверенная, но для серверов
>                 приложений, типа Zope, которые однажды стартуют и месяц
>                 работают, довольно перспективная. В некоторых вариантах
>                 использования (Live CD например), просто незаменимая.
> 
>                 
>             2.  Видимо, пакеты будут разрезаны на python-<MODULE> &
>                 python-<MODULE>-src, при этом python-<MODULE> содержит файлы
>                 pyo и (или) pyc, а ...-src - файлы py.

Не стоит. Python - скриптовый язык, и пусть модули сохраняют
скриптовый вид. Если нужна "компактность, компактность, компактность",
пользуйтесь zip-ованными архивами, которые поддерживает python 2.3
Кто-нибудь вообще проверял работоспособность python на одних
.py[co] без исходника? Отладка точно пострадает. Что-нибудь ещё?


Спасибо Андрею и Алексею за недюжинную работу.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
life, n.:
	Learning about people the hard way -- by being one.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]