[devel] Re: A: Полиси ( я свел все воедино ) + FAQ
Mikhail Zabaluev
=?iso-8859-1?q?mhz_=CE=C1_altlinux=2Eorg?=
Пн Фев 23 00:40:59 MSK 2004
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.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20040223/61f7961c/attachment-0002.bin>
Подробная информация о списке рассылки Devel