* [devel] A: Полиси ( я свел все воедино ) + FAQ
@ 2004-02-22 19:32 Andrey Orlov
2004-02-22 21:40 ` [devel] " Mikhail Zabaluev
0 siblings, 1 reply; 11+ messages in thread
From: Andrey Orlov @ 2004-02-22 19:32 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 28024 bytes --]
Hi!
Я свел в единое целое все наши высказывания по поводу полиси и то, чего мы хотим.
В дальнейшем, желательно при обсуждении ссылатся на пункты этого полиси, так
как то, что мы хотим добится на данном этапе - это то, что перечислено здесь, все
остальное - немножко экспериментальные разработки, вопросы по полиси приветствуются,
предложения тоже. На вопросы я (мы) ответим, добавим ответы в FAQ (его начало приведено
в конце), с предожениями будет несколько хуже, но все равно приветствуются.
Касаемо формата - поддерживаю пока я, формат - удобный для меня. Если мы его воплотим
в жизнь, то я попробую включить его куда-то в docs@ переведя в docbook (это не проблема).
На остальные вопросы по поддержке ответы в FAQ в конце. Текущая версия файла макросов
и примера спека (экспериментальная, IMHO), приаттачена (недавно пробегала в расслке, конечно,
но чбы все было вместе....)
==== cut =============
================================================================================
$Id: 1:Python_EPOCH.txt 35 2004-02-22 16:55:47Z cray $
--------------------------------------------------------------------------------
Краткое описание жизненного цикла питона в репозитории :
Жизненный цикл с точки зрения мантейнеров :
1. В любой момент времени существует единственный основной пакет
python - пакет с именем python;
2. В день выхода новой минорной версии python (X.Y), делается форк:
новая версия собирается под именем python, тогда как старая -
под именем pythonXY-1;
Замечание 1: Более строго было бы использовать имя pythonX.Y-1,
но тут сложилась некая традиция, не уверен, что хорошая;
3. После выхода новой минорной версии, все мантейнеры уведомляются
о необходимости пересборки и тестирования модулей с новой
версией python;
4. Если через некоторое время (например - 1 месяц) модуль не был
пересобран - он удаляется из репозитория (кажется, это
называется orphaned);
5. Как и раньше, основной версией python в Sysiphus является
последняя пересобранная, старые версии лежат только для тестовых
целей в дистрибутив, если таковой будет собираться на основе
Sysiphus не входят;
6. Как следствие п.5, все модули в Sysiphus будут собираться и
поставлятся только с последней версией;
7. При необходимости, любой потребитель Sysiphus может пересобрать
модуль под старую версию python и самостоятельно использовать
ее. Новая схема сборки допускает такую возможность указанием
ключа --with pythonMN;
8. Новая схема сборки допускает решение, при котором в дистрибутив
входят две и более версии языка 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), скорее всего, нет: новые фичи в питон
для того и вводятся, чбы их использовать, и примеров я могу
привести достаточно много;
Жизненный цикл с точки зрения потребителей :
1. Потребитель регулярно издает команду :
apt-get upgrade (или dist-upgrade)
Потребитель, не делающий этого, очевидно, не является
потребителем Sysiphus и о нем в этом разделе речи не идет ;)
2. Потребитель следит за тем, чбы апгрейд проходил нормально (т.е.
новые версии python и модулей к нему ставились), при этом
"любимые" модули не сносились;
3. Если потребитель увидел что-то типа "python-X.Y.Z will be
upgraded, but python-module-IMPORTANT will be removed", то это
повод писать письма мантейнеру модуля IMPORTANT с просьбами его
пересобрать. Конфликты такого рода решаются в рамках стандартной
POLICY Alt Linux Team и не являются python-специфичными;
4. Новая схема сборки модулей гарантирует (зависмостямb)
невозмиожность установки модулей от старых версий python с его
новыми версиями (по крайней мере на уровне минорных версий,
нужно ли затрагивать сабминоры - вопрос открытый, выйдет
python2.3.4 - посмотрим);
================================================================================
================================================================================
$Id: 2:Python_RPM.txt 35 2004-02-22 16:55:47Z cray $
--------------------------------------------------------------------------------
Правила работы с пакетом python
Небольшая преамбула : эти правила написаны по мотивам прототипа пакета
под названием test. Кое-что изменилось (я не стал вводить модуль
python-strict и python-core), но я не уверен еще в валидности этих
изменений: не все работает нормально. Вполне возможно, что
python-strict & python-core будут возвращены;
Состав пакета :
Я медленно, но верно, пилю питон на части. Новый пакет будет состоять
примерно из следующих частей :
python, python-base -- минимальная установка питона, достаточная
для его работы, практически не содержит модулей;
python-modules -- псевдопакет, содержащий зависимости на все
модули питон, рекомендованные к установке (не рекомендован,
в частности, пакет python-obsoletes);
python-obsoletes -- пакет, содержащий фрагменты 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, что будет приводить к установке всех необходимых пакетов. После
их решения - зависимости в ваши модули будут проставлены автоматически.
Правила работы с пакетом :
Чбы проиллюстрировать работу, просто приведу несколько команд:
1. Установка старой версии :
apt-get install python22
2.1 Обновление ее до новой версии (старая версия будет снесена):
apt-get install python
2.2 Установка новой версии с сохранением старой (для тех кому
надо):
apt-get install python-weak
2.2.1 Удаление старой версии
apt-get install pythno
Обычные пользователи проводят систему через стадии 1, 2.1; Разработчики,
которым некоторое время могут быть реально нужны обе версии python,
проводят систему через стадии 1, 2.2, 2.2.1, понимая при этом, что на
стадии 2.2 система может оказаться не юзабельной, по причине некоректности
зависимостей: python-weak менее требователен к зависимостям, и, в частности,
допускает совместную установку с python старых версий.
================================================================================
================================================================================
$Id: 3:Python_MODULE.txt 36 2004-02-22 17:03:59Z cray $
--------------------------------------------------------------------------------
Правила сборки и офрмления модуля для языка python
1. Модуль для python собирается с префиксом python-module-;
2. Модуль для одной из старых версий pythonX.Y собирается с префиксом
pythonX.Y-module-;
3. Модуль должен содержать явно указанную зависимость на версию питон,
использованный при его сборке, такая зависимость вводится указанием
кляузы вида :
python = %__python_version
(Здесь есть некоторые тонкости, которых не было при использовании
старой схемы, поэтому вопрос сейчас изучается, возможны изменения);
4. В параметре GROUP спека должен быть указан Development/Python/Modules;
5. Для сборки модуля рекомендуетсся использовать темплейт, предложенный
Алексеем Морозовым для модуля python-serial, но его использование не
обязательно. По крайней мере, пока;
6. Отключать повторную байт-компиляцию python не рекомендуется, так как
иначе скомпилированные модули могут выводить некорректную диагностику
ошибок (неверный путь к файлу), что крайне неудобно (посыпятся жалобы
вида "ваша програма упала в /home/vasya/petya.py, а такого файла вообще
нет"). Я это проверил (и диагностику, и жалобы);
7. Пример спека будет включен в пакет python-builds или как-то типа того,
когда таковой появится, чбы добавить макросы в rpm и улучшенную тулзу
для байт-компиляции модулей. Работы в этом направлении сейчас ведутся;
Использование стандартного спека (я сам не проверял, цитирую автора) :
1. Сборка :
rpmbuild -ba pyserial.spec
На выходе будет python-pyserial-*.rpm, причем, бинарные rpm привязаны к
текущей (вероятно, 2.3) версии python.
2. Сборка под конкретный питон:
rpmbuild -ba pyserial.spec --with pythonXY
на выходе будут получаться pythonXY-pyserial...rpm, (AO:
напомню, что использование такого варианта сборки пока
ориентировано на частное использование);
В данный момент, в качестве XY может использоваться 22, 23 и
(задел на будущее) 24.
Зависимости на пакеты с другими модулями python надо прописывать как
Requires: python%__python_package_version-<anotherModule>
В текущем варианте, насколько известно, последующая пересборка pythonXY-что-то там
без ключа приведет к попытке сборки под "основной" питон. Это не самая большая
проблема, так как пока ключик --with ориентирован на домашнее использование.
================================================================================
================================================================================
$Id: 4:Python_TOOLS.txt 35 2004-02-22 16:55:47Z cray $
--------------------------------------------------------------------------------
Правила сборки и оформления прикладных пакетов, использующих python :
На правах обсуждения, пока что так собраны только мои пакеты, да и то -
не все: Zope & rPAS. rPAS в сизифе пока нет, но будет, это корба сервер
приложений, альфа версия и все такое, впрочем неважно.
1. Прикладной пакет <TOOL> размещается в каталоге
<PREFIX> :== '/usr/lib/' <TOOL>,
если его использование предполагается только с основной версией
python (например, Zope, rPAS);
2. Если возможно использование прикладного пакета с каждой из
версий python (например IDLE), то пакет размещается в каталоге
<PREFIX> :== '/usr/lib/pythonNM/tools/' <TOOL>.
3. Специфичные для пакета модули устанавливаются в <PREFIX>/lib
(если пакет при старте корректирует соотв. образом PYTHON_PATH
или обладает специальной подсистемой импортирования модулей,
отчуждаемые
- в site-packages. Например, Zope поставляет отчуждаемые модули
ZODB, DTMLDocuments, etc;
4. Головной модуль пакета живет где-то в <PREFIX>/tool.py;
5. На головной модуль стоит симлинк /usr/bin/<TOOL> или
/usr/sbin/<TOOL>;
6. Симлинки на головные модули пакетов, устанавливаемых многократно
с специфичными версиями python должны управлятся посредством
alternatives, что позволяет избежать ситуации, с запуском
головного модуля с неправильным питоном (так как alterantaives
изменит симлинк на tool одновременно с изменением симлинка на
python, а кто запускает tool не из /usr/bin - тот,
предположительно, знает, что делает). Альтернативный
альтернативам вариант - изменение записи в
#! - представляется трудоемким (хотя оптимизировать, конечно,
можно) и излишним (альтернативы решают проблему);
7. Именование пакетов: я не сталкивался, пока, с прикладными
пакетами, которые не входили бы в python (как например IDLE), но
требовали бы (от меня) возможности сборки с каждым из
альтернативных питонов. Честно говоря, разводить зоопарк с Zope
для каждого питона - крайне неразумно. Я предполагаю возможность
появления необходимости сборки с одним из альтернативных питонов
(в случае с Zope избежать этого удавалось с некоторым
напряжением), но и в этом случае мы будем иметь дело только с
одним пакетом (правда, в этом случае в заголовке стартового
модуля потребуется-таки вписать путь к правильному питону).
Поэтому какое-либо префиксирование кажется излишним.
Все остальное, типа /etc/init.d/toold, /var/lib/tool не является
python-специфичным. Описанные предложения (требования) проверены
опытом, это работает и это удобно.
================================================================================
================================================================================
$Id: 5:Python_FAQ.txt 37 2004-02-22 17:35:16Z cray $
--------------------------------------------------------------------------------
Часто задаваемые вопросы :
Я первые несколько придумал сам, остальные буду добавлять по мере
возникновения.
Q1: Где можно взять текст данной Policy?
A1: До появления нового пакета python в сизифе - можно прочитать в
рассылке или обратится ко мне, cray@neural.ru. После появления - в
каталоге
/usr/share/doc/python-devel или типа того. Размещение данного policy
в рамках altlinux docs team возможно, но пока не обсуждалось (опять
же, до вступления в силу - преждевременно);
Q2: Как внести изменения в Policy?
A2: Отослать их мне, на cray_python@neural.ru. Я их с вами обсужу.
Необходимое условие продуктивности обсуждения - вы подписаны на
devel@altlinux.ru. Все остальные изменения прочитываются и
принимаются к сведенью;
Q3: Кто автор Policy и почему?
A3: Автор - комьюнити. Идея полиси возникла летом 2003-го года (cray,
doc, ldv и др), когда некоторые основные идеи были согласованы, но в
дальнейшем не развивалась - все что-то тихо клепали, но особого
взаимного интереса не проявляли. Существенный вклад сделал Алексей
Морозов, заставивший меня начать шевелится и Алексей Любимов,
заставивший меня увидеть некоторую проблему.
Поддерживаю полиси я, Андрей Орлов, мантейнер пакета python & Zope.
Я же обладаю (наверно) каким-то решающим голосом. Почему я? Потому
что логично поручить это мантейнеру python. Будет другой мантейнер
python - видимо, он же будет рулить и полиси. Почему решающим?
Потому что должен же кто-то выбрать из двух стогов сена один ;), а я
достаточно туп и ленив, чбы :
a) Не делать лишних шагов;
b) Не вдаватся в многочисленный тонкости: лучше
удовлетворительное решение сегодня, чем замечательное -
через год (тем более, что через год оно так и так будет);
По-моему это главное требование к решающему голосу, впрочем, по
спорным вопросам я консультируюсь LDV, и, возможно, настоящий
решающий голос все-таки принадлежит LDV, только я об этом не знаю.
Q4: Я считаю что макрос такой-то и сякой-то, используемый при сборке
"стандартного" модуля неудачный. К кому мне обратится?
A4: К Алексею Морозову. Он кашу с макросами заварил - ему и
расхлебывать. Я рад, что нашелся человек, который это сделал, и
заглянув в эти макросы, я подумал - что он знает, что делает. Мне
про макросы лучше не писать, результат может быть неадекватный
(разве что в рамках п.QA2).
Q5: Почему бы не сделать тоже самое на основе Distutils ?
A5: Основная идея Distutils - собрать по некоторому универсальному
конфигурационному файлу информацию об использумемой операционной
системе и (в случае rpm) сгенерировать под нее спецификацию.
Спецификация генерируется по некоторому "умозрительнному" темплейту,
текущий пример python-module-serial первый шаг на пути к нему. Так
что можно надеятся, что Distutils будет следующим шагом.
В то же время, уже давным-давно, Paul Uzorin написал пакет
libAltDist, который с некоторых пор я мантейню, так как с его
помощью собираются некоторые другие пакеты, которые я забрал у Паши,
чбы освободить его для более важных дел. libAltDist реально
позволяет сгенирировать спецификацию rpm соотв. полиси AltLinuxTeam
и поддерживать ее (там cleanup_spec, add_changelog, etc). libAltDist
не очень хорошо продуман / написан, но общая идея правильная. Если
кто-то возьмется его разрабатывать - это может быть следующий шаг к
пересборке пакетов посредством distutils, мы с Алексеем Морозов
можем поддержать такое начинанеие (я - как мантейнер этого пакета,
Алексей - как автор python-serial.spec);
Q6: Когда и как все это вступит в силу?
A6: Уже вступило. Первые эксперименты ставятся в репозитории Дедалус.
Как только мы получим работающее подмножество Сизифус, собранное по
новой схеме - будет выпущена релизная версия этой полиси и остальным
следует присоеденится. После чего (возможно, в процессе
присоединения остальных) все будет перенесено в Сизиф. Это будет
страшный день для наших пользователей. Один из работничков - я -
ограничен во времени, так что ориентировочная дата страшного дня -
14 марта.
Q7: Можно ли прочитать какой-нить график перехода на новую схему?
A7: Да, можно. Каждую неделю будет публиковаться в рассылке
devel@altlinux.ru, первая версия уже была опубликована.
Q8: Кто принимает непосредственное участие в переходе?
A8: В ближайшее время - т.е. до выхода финальной версии полиси - я и
Алексей Морозов. До появляения в дедалусе работоспособного питона
остальным приисоеденятся не советую, впрочем - это вопрос ближайших
дней.
Q9: Почему питонов много, а python-doc - один.
A9: Черт его знает. До недавнего обращения мантейнера python-doc с
просьбой забрать пакет я об этом не задумывался, и на самом деле
было даже два python-doc
- второй в рамках python23 и под названием python23-info. Наверно,
держать доки под каждый python все-таки неразумно и python23-info
откочует в 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.
3. Что касается включение файлов pyc или pyo, то возможны три
варианта:
- Включение обеих (сейчас этот вариант представляется
- единстенным возможным);
- Включение на стадии сборки одного из типов файлов
(требует спеиальных макросов, что Алексей обещает
сделать, или ручной работы, также требует патчить
питон);
- Включение политики установки по аналогии с
%_install_langs (я стою за этот вариант, так как у
потребителя остается выбор, который он может сделать
в зависимости от своих потребностей, но это требует
патчить не только python, но и rpm;
4. Зависимости ставятся только на основной пакет т.е.
python-<MODULE>, пакет с исходными текстами используется
только разработчиками или теми, кому нужна "грязная"
настройка (ставим -src, редактируем один из файлов, все
остальное сносим, один файл оставляем, кажется это можно
автоматизировать, но я не пробовал);
Данный ответ дан на основе личных убеждений, разговоров с Алексеем и
писем в рассылке.
Q11: Когда будет python24 и где его взять?
A11: До выхода релиза - только в дедале. Сейчас его там нет ;), но по
завершении возни с переходом на новую схему сборки я его соберу.
Q12: Когда появится Zope27?
A12: Offtopic! offtopic! На самом деле, я не знаю чем 27 лучше чем 264.
Хотя, конечно, какие-то отличия есть. Именно из-за них мягкий
переход на 27 невозможен (придется кой-че переписать в обвязке), но
к концу марта можно ждать сборку в дедале. Мы держим сервер
разработки синхронный с сизифом, так что внезапное обрушение
коммерческих проектов компании Freehand, которая любезно финансирует
поддержку python & Zope мной, крайне нежелательно, поэтому появление
Z27 в сизифе возможно только после того, как я буду убежден, что он
реально работает. До сих пор (на примере 2.3.0, 2.4.0, 2.5.0, 2.6.0,
и мбть даже 2.1.0 & 2.2.0 (но это было очень давно и я уже не
помню)) ни одна версия с нулевым минором не работала корректно. На
возможные возражения отвечу: сложность Zope такова, что
WEB-разработчик, не знающий коды Zope досконально, обнаружить
некорректность может только чудом. Тем более, что редкий
WEB-разработчик использует возможности собственно Zope хотя бы на
5%.
Q13: Как собирать пакеты под Zope?
A13: Пакеты под Zope - это пакеты под Zope. К пакетам под python имеют
довольно отдаленное отношение. Главный сборщик пакетов под Zope,
сейчас, Генадий Ковалев, мантейнер Plone, наверно его опыт будет вам
более полезен чем мой, тем более, что то что мы с ним делаем мы
между собой согласовали.
Пока что у меня других вопросов не возникло, так что присылайте.
================================================================================
==== cut =============
--
WthBstRgrds -- Андрей Орлов --
--- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------
[-- Attachment #2: pyserial.spec --]
[-- Type: text/plain, Size: 2858 bytes --]
# -*- coding: utf-8 -*-
%define version 2.0
%define release alt2
%setup_python_module pyserial
Summary: Serial port access for python
Summary(ru_RU.UTF-8): п■п╬я│я┌я┐п© п╨ п©п╬я│п╩п╣п╢п╬п╡п╟я┌п╣п╩я▄п╫п╬п╪я┐ п©п╬я─я┌я┐ п╦п╥ python
Name: %packagename
Version: %version
Release: %release
Source: %modulename-%version.zip
License: Python
Group: Development/Python
Prefix: %_prefix
Url: http://pyserial.sf.net
# Automatically added by buildreq on Wed Jan 14 2004
BuildRequires: unzip
%description
This module capsulates the access for the serial port. It provides
backends for standard Python running on Windows, Linux, BSD (possibly
any POSIX compilant system) and Jython. The module automaticaly
selects the appropriate backend.
This module is built for python %__python_version
%description -l ru_RU.UTF-8
п║ п©п╬п╪п╬я┴я▄я▌ я█я┌п╬пЁп╬ п╪п╬п╢я┐п╩я▐ п╪п╬п╤п╫п╬ я─п╟п╠п╬я┌п╟я┌я▄ я│ п©п╬я│п╩п╣п╢п╬п╡п╟я┌п╣п╩я▄п╫я▀п╪ п©п╬я─я┌п╬п╪ п╡
я│я┌п╟п╫п╢п╟я─я┌п╫п╬п╪ Python, п╥п╟п©я┐я┴п╣п╫п╫п╬п╪ п╫п╟ Windows, Linux, BSD (п╡п╬п╥п╪п╬п╤п╫п╬, п╩я▌п╠п╬п╧
POSIX-я│п╬п╡п╪п╣я│я┌п╦п╪п╬п╧ я│п╦я│я┌п╣п╪п╣) п╦п╩п╦ Jython. п°п╬п╢я┐п╩я▄ п╟п╡я┌п╬п╪п╟я┌п╦я┤п╣я│п╨п╦ п╡я▀п╠п╦я─п╟п╣я┌
п©п╬п╢я┘п╬п╢я▐я┴п╦п╧ п╢п╩я▐ п╢п╟п╫п╫п╬п╧ я│п╦я│я┌п╣п╪я▀ п╪п╣я┘п╟п╫п╦п╥п╪ п╢п╬я│я┌я┐п©п╟.
п╜я┌п╬я┌ п╪п╬п╢я┐п╩я▄ я│п╬п╠я─п╟п╫ п╢п╩я▐ Python п╡п╣я─я│п╦п╦ %__python_version
%package -n python-%modulename-doc
Summary: %modulename documentation and example programs
Summary(ru_RU.UTF-8): п■п╬п╨я┐п╪п╣п╫я┌п╟я├п╦я▐ п©п╬ API п╦ п©я─п╦п╪п╣я─я▀ п©я─п╬пЁя─п╟п╪п╪ п╢п╩я▐ %modulename
Group: Development/Python
Prefix: %_prefix
Requires: python-%modulename = %version
%description -n python-%modulename-doc
%modulename provides portable way to access serial ports in various
systems. Install python-%modulename-doc if you need API documentation
and examples for this module
%description -n python-%modulename-doc -l ru_RU.UTF-8
%modulename п©я─п╣п╢п╬я│я┌п╟п╡п╩я▐п╣я┌ я┐п╫п╦я└п╦я├п╦я─п╬п╡п╟п╫п╫я▀п╧ п╢п╬я│я┌я┐п© п╨ п©п╬я│п╩п╣п╢п╬п╡п╟я┌п╣п╩я▄п╫п╬п╪я┐
п©п╬я─я┌я┐ п╡ я─п╟п╥п╫я▀я┘ я│п╦я│я┌п╣п╪п╟я┘. пёя│я┌п╟п╫п╬п╡п╦я┌п╣ python-%modulename-doc, п╣я│п╩п╦ п▓п╟п╪
я┌я─п╣п╠я┐п╣я┌я│я▐ п╢п╬п╨я┐п╪п╣п╫я┌п╟я├п╦я▐ п©п╬ API п╦ п©я─п╦п╪п╣я─я▀ п©я─п╬пЁя─п╟п╪п╪п╦я─п╬п╡п╟п╫п╦я▐ я│
п╦я│п©п╬п╩я▄п╥п╬п╡п╟п╫п╦п╣п╪ п╢п╟п╫п╫п╬пЁп╬ п╪п╬п╢я┐п╩я▐.
%prep
%setup -q -n %modulename-%version
%build
mkdir -p buildroot
# Unfortunately build and install steps should be done at once
# because otherwise .pyo files won't get into INSTALLED_FILES
# record
CFLAGS="%optflags" %__python setup.py \
install --optimize=2 \
--root=`pwd`/buildroot \
--record=INSTALLED_FILES
%install
cp -pr buildroot %buildroot/
unset RPM_PYTHON
%files -f INSTALLED_FILES
%doc changes.txt readme.txt
%files -n python-%modulename-doc
%doc examples
%changelog
* Wed Jan 14 2004 Alexey Morozov <morozov@altlinux.org> 2.0-alt1
- Initial build for ALT Linux
[-- Attachment #3: python_macros --]
[-- Type: text/plain, Size: 1115 bytes --]
%check_python_version_internal() \
%{expand: %{expand:%%{?_with_python%{2}:%%{?__python_package_version:%%%%{error:Only one python version can be selected at a time}}}}} \
%(echo %{expand:%%{?_with_python%{2}:%%{?__python_package_version:BuildConflicts: python = %{1}}}}) \
%(echo %{expand:%%{?_with_python%{2}:BuildPreReq: python = %{1}}}) \
%{expand: %{expand:%%{?_with_python%{2}:%%%%global __python %(which python%1 2>/dev/null || echo /bin/false)}}} \
%{expand: %{expand:%%{?_with_python%{2}:%%{!?__python_package_version:%%%%global __python_package_version %2}}}}
%check_python_version() \
%{expand: %%check_python_version_internal %{1} %(echo %1 | sed -e 's/\\.//g')}
%setup_python_module() \
%{expand: %%global modulename %{1}} \
%(echo Provides: python-%{1} = %version-%release) \
%check_python_version 2.2 \
%check_python_version 2.3 \
%check_python_version 2.4 \
%{expand: %{expand: %%{!?__python_package_version:%%%%global __python_package_version %%%%nil}}} \
%{expand: %%global packagename python%%{__python_package_version}-%%{modulename}} \
%(echo %{expand:Requires: python = %%__python_version})
^ permalink raw reply [flat|nested] 11+ messages in thread
* [devel] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-22 19:32 [devel] A: Полиси ( я свел все воедино ) + FAQ Andrey Orlov
@ 2004-02-22 21:40 ` Mikhail Zabaluev
2004-02-22 22:18 ` Mikhail Zabaluev
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Mikhail Zabaluev @ 2004-02-22 21:40 UTC (permalink / raw)
To: Andrey Orlov; +Cc: devel, cray_python
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* [devel] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-22 21:40 ` [devel] " Mikhail Zabaluev
@ 2004-02-22 22:18 ` Mikhail Zabaluev
2004-02-22 22:34 ` Dmitry V. Levin
2004-02-23 6:50 ` [devel] " Andrey Orlov
2 siblings, 0 replies; 11+ messages in thread
From: Mikhail Zabaluev @ 2004-02-22 22:18 UTC (permalink / raw)
To: devel; +Cc: Andrey Orlov
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
Hello Andrey,
On Mon, Feb 23, 2004 at 12:40:59AM +0300, Mikhail Zabaluev wrote:
>
> > 2. В день выхода новой минорной версии python (X.Y), делается форк:
> > новая версия собирается под именем python, тогда как старая -
> > под именем pythonXY-1;
>
> Что за "-1"? Почему не просто pythonXY версии X.Y.Z, как у людей?
Это впоследствии понял правильно, можно не объяснять.
--
Stay tuned,
MhZ JID: mhz@altlinux.org
___________
The ultimate game show will be the one where somebody gets killed at the end.
-- Chuck Barris, creator of "The Gong Show"
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [devel] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-22 21:40 ` [devel] " Mikhail Zabaluev
2004-02-22 22:18 ` Mikhail Zabaluev
@ 2004-02-22 22:34 ` Dmitry V. Levin
2004-02-22 22:57 ` [devel] " Денис Смирнов
2004-02-23 6:37 ` [devel] " Andrey Orlov
2004-02-23 6:50 ` [devel] " Andrey Orlov
2 siblings, 2 replies; 11+ messages in thread
From: Dmitry V. Levin @ 2004-02-22 22:34 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
On Mon, Feb 23, 2004 at 12:40:59AM +0300, Mikhail Zabaluev wrote:
> On Sun, Feb 22, 2004 at 10:32:27PM +0300, Andrey Orlov wrote:
[...]
> > 2. В день выхода новой минорной версии python (X.Y), делается форк:
> > новая версия собирается под именем python, тогда как старая -
> > под именем pythonXY-1;
> > Замечание 1: Более строго было бы использовать имя pythonX.Y-1,
> > но тут сложилась некая традиция, не уверен, что хорошая;
>
> Это какой-то ментальный блок, существующий со времён kernelXY,
> а то и раньше.
>
> -------------- лирическое отступление --------------------
> Ещё раз, для всех, кого тянет придумать новый причудливый суффикс для
> зашифровывания номера версии, чтобы никто не догадался: точку в имени
s/в имени/в суффиксе имени/
> пакета использовать МОЖНО и желательно. Подчёркивание между собственно
> именем и номером версии как частью имени использовать можно, но
> нежелательно (дело эстетики, как в случае с libtool_1.x: без
> подчёркивания становится трудночитабельно).
> Дефис AKA минус в именах пакетов использовать НЕЛЬЗЯ, это грех перед
> Богом, за который вас заставят 1000 лет пересобирать пакеты в чистилище.
> ----------------------------------------------------------
Будем считать, что это policy.
Ещё бы в виде патча на alt-packaging/conventions.tex
[...]
> Спасибо Андрею и Алексею за недюжинную работу.
Присоединяюсь.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [devel] A: Полиси ( я свел все воедино ) + FAQ
2004-02-22 22:34 ` Dmitry V. Levin
@ 2004-02-22 22:57 ` Денис Смирнов
2004-02-23 6:37 ` [devel] " Andrey Orlov
1 sibling, 0 replies; 11+ messages in thread
From: Денис Смирнов @ 2004-02-22 22:57 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
On Mon, Feb 23, 2004 at 01:34:16AM +0300, Dmitry V. Levin wrote:
>> Дефис AKA минус в именах пакетов использовать НЕЛЬЗЯ, это грех перед
>> Богом, за который вас заставят 1000 лет пересобирать пакеты в чистилище.
DVL> Будем считать, что это policy.
5+
:)
--
С уважением, Денис
http://freesource.info
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [devel] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-22 22:34 ` Dmitry V. Levin
2004-02-22 22:57 ` [devel] " Денис Смирнов
@ 2004-02-23 6:37 ` Andrey Orlov
2004-02-23 7:32 ` [devel][JT] " Andrey Rahmatullin
1 sibling, 1 reply; 11+ messages in thread
From: Andrey Orlov @ 2004-02-23 6:37 UTC (permalink / raw)
To: ALT Devel discussion list
On Monday 23 February 2004 01:34, Dmitry V. Levin wrote:
> > Дефис AKA минус в именах пакетов использовать НЕЛЬЗЯ, это грех перед
> > Богом, за который вас заставят 1000 лет пересобирать пакеты в чистилище.
> Будем считать, что это policy.
Я не могу понять только одно. _Где_ все увидели дефис в имени ;). Видимо,
я не слишком аккуратно объяснил: "-" в даном случае - это Y-1, т.е. предыдущая версия.
Если (X,Y) = (2,4), то pythonXY-1 = python23.
Забавно, что не расписанную явно подстановку X и Y, все поняли, и никто не написал
про "Зачем X, почему бы не использовать цифры", а вот минус как арифметическую операцию
приняли за дефис. Ладно, я внес необходимые разъяснения в полиси, спасибо за комментарий.
А то и впрямь у когонть всплыла бы зависимость на пакет под именем "python24-1",
"python24-1-1", "python24-2", etc.
ЗЫ: Еще более загадочно, что ранее фигуровавшее обозначение pythonXY+1 таких
вопросов не вызывало.
--
WthBstRgrds -- Андрей Орлов --
--- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* [devel] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-22 21:40 ` [devel] " Mikhail Zabaluev
2004-02-22 22:18 ` Mikhail Zabaluev
2004-02-22 22:34 ` Dmitry V. Levin
@ 2004-02-23 6:50 ` Andrey Orlov
2004-02-24 0:16 ` Mikhail Zabaluev
2 siblings, 1 reply; 11+ messages in thread
From: Andrey Orlov @ 2004-02-23 6:50 UTC (permalink / raw)
To: ALT Devel discussion list
On Monday 23 February 2004 00:40, you wrote:
> 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, как у людей?
Если (X,Y) == (2,4), то pythonXY-1 == python23, подстрока Y-1 обозначала
"предыдущую версию".
> > Замечание 1: Более строго было бы использовать имя
> > pythonX.Y-1, но тут сложилась некая традиция, не уверен, что хорошая;
>
> Это какой-то ментальный блок, существующий со времён kernelXY,
> а то и раньше.
Да, наверно. Мне так тоже неудобно.
> > 4. Новая схема сборки модулей гарантирует (зависмостямb)
> > невозмиожность установки модулей от старых версий python с
> > его новыми версиями
>
> По-моему, слишком жёсткое ограничение.
Нет, не слишком, если мы хотим более-менее надежной работы.
> Нужно решить лишь такую задачу: если есть зависимость между модулями,
> эта зависимость должна учитывать версию python ABI. Как этого можно
> достичь, я писал.
Увы, но синтаксис языка тоже менятся, не оставаясь до конца совместимым
ни вперед, ни назад. Zope для версии 2.2 разражается кучей предупреждений
и ввалится, при запуске с 2.3, причем исключительно из-за проблем синтаксиса.
> > (по крайней мере на уровне минорных версий,
> > нужно ли затрагивать сабминоры - вопрос открытый, выйдет
> > python2.3.4 - посмотрим);
>
> Я думаю, можно полагаться на неявное обязательство разработчиков
> Python не ломать ABI между микро-релизами.
Я тоже думаю, только как я уже написал - дело не в ABI, а в синтаксисе.
> > Я медленно, но верно, пилю питон на части.
>
> В этом процессе главное -- чувство меры ;)
Потому и медленно. Нет, я не пытаюсь распилить его на "все" модули, по одному файлу
на пакет. Только на крупные группы: python-modules-xml, python-modules-http, примерно так.
> Я правильно понял, что python это "панама", которая тянет python-base
> и python-modules?
Да, python-weak - вторая панама, которая провайдит python.
> > python-obsoletes -- пакет, содержащий фрагменты python,
> > которые объявлены устаревшими (например, rotor.py) или несекъюрными (он
> > же, в более ранее время);
>
> s/obsoletes/obsolete/ -- чтоб было более понятно по-английски.
Thnks.
> > python-modules-* -- много модулей, реально каждый пакет
> > содежит большую группу модулей, относящихся к примерно-одной тематике,
> > над автоматической кластеризацией я сейчас работаю;
> Я против избыточной "кластеризации" bundled модулей примерно по тем же
> причинам, по которым протестовал против отщепления модулей perl от
> штатной сборки.
Про перл не читал, избыточной не будет.
> По крайней мере, такое правило должно соблюдаться: если пользователь ставит
> apt-get install python python-doc
> он вправе расчитывать на наличие всех модулей, о которых написано в
Соблюдается. Правда, в перспективе, скорее python, python-modules, python-doc.
зависимость python / python-modules - временное решение.
> плюс подобранного вручную набора python-modules-* может быть полезна.
> Просто не нужно подвергать этому всех пользователей.
Я где-то предлагал иное?
> Вдобавок, без автоматического определения зависимостей
> возникнут проблемы у разработчиков, которым вместо одной зависимости
> на python = %__python_version как на всю платформу придётся смотреть,
> какие микропакеты реально нужны для работы.
Об этом было сказано в конце парграфа, вы просто не дочитали.
> > python-tools-* -- различные инструменты для и на python,
> > например python-tools-idle;
> Это есть хорошо. Idle должен был отпочковаться.
Уже. Даже в сизифе лежит уже месяц.
> > python-weak -- python с облегченными зависимостями,
> > допускающий провести совместную установку со старой версий pythonX.Y
>
> Я чую ненужную сложность.
> не будет установлен. Отпустите python-weak в пространство
> невоплощённых идей.
Не отпущу. Вам не мешает - мне нужно, некоторым другим - тоже. Кроме того, это работает.
> Вдогонку: если апгрейд модуля/приложения требует python = 2.3, почему
> бы не иметь в дистрибутиве python23, который благополучно вытянется,
> если он такое предоставляет? У нас уже организовано так несколько
> семейств пакетов, стоит ли здесь изобретать велосипеды?
Текущая схема с несколькими семействами пакетов обладает рядом недостатков,
которые были описаны и обсуждены ранее. Вам стоит вернутся к началу обсуждения.
Впрочем, я попробую включить ответ на отот вопрос в FAQ.
> Сделайте исключение. Слишком многие знают старика под этим именем.
Provides: tkinter. Не вижу проблем.
>
> > 2.2.1 Удаление старой версии
> >
> > apt-get install pythno
>
> Не уверен, что правильно понял.
Установка новой версии командой apt-get install python приведет
к сносу старой версии, из-за существующего между ними конфликта.
>
> > 4. В параметре GROUP спека должен быть указан
> > Development/Python/Modules;
>
> Что же тогда останется в Development/Python? :)
> Присоединяюсь к уже высказанному мнению, что в новой группе нет нужды.
Порядка 20ти пакетов самого пакета python, различные python-tools для разработки.
Уже высказанное мнение, звучало, помнится, как "если она действительно нужна, то будет создана".
> > Зависимости на пакеты с другими модулями python надо
> > прописывать как
> >
> > Requires: python%__python_package_version-<anotherModule>
>
> Хотелось бы здесь поиметь автоматику...
Мы думаем над этим.
> Hint от соразработчика perl.{req,prov}, поимевшего кучу головной боли с
> синтаксисом Perl: в скриптах на Python, хвала ему и его разработчикам,
[skip]
> > '/' для получения относительного пути к файлу модуля (без суффикса
> .py) или каталогу с файлом __init__.py
Или файлу *zip, или *.so (с четырьмя разными доп.суффиксами), или вообще отсутвствующему
файлу, и наконец - еще есть перекрытая функция __import__ и приложения,
изменяющие python_path. Причем, достаточно распространенным способом.
Так что, к сожалению, не все так просто, я уже попробовал. Пока что скрипт, эксплуатирующий
машину импорта самого python дает существенно более полный список зависимостей,
чем всякие игры с регексп.
> > 6. Симлинки на головные модули пакетов, устанавливаемых
> > многократно с специфичными версиями python должны управлятся посредством
> > alternatives, что позволяет избежать ситуации, с запуском головного
> Интересно, как вы этого добьётесь, если python и инструмент
> устанавливаются раздельно и используют отдельные конфигурации
> для alternatives (slave невозможен).
Пока что я этого добиваюсь, так как все такие пакеты мои и являются частью питона,
как например idle и pynche.
> Поддерживаю. Однако, python-doc отяжелеет от всего многообразия форматов.
Да, есть такая опасность. Пока что меня больше трогало то, что html-документация на
python это не все, и даже не самое интересное (удобное). Начнет тяжелеть - будем решать.
Что до info vs html ... Почему-то мне info ближе.
> Не стоит. Python - скриптовый язык, и пусть модули сохраняют
> скриптовый вид. Если нужна "компактность, компактность, компактность",
> пользуйтесь zip-ованными архивами, которые поддерживает python 2.3
Нужна не только компактность, но и быстродействие, а также некая степень
защищенности от случайного вмешательства со стороны любителя "грязной"
настройки.
> Кто-нибудь вообще проверял работоспособность python на одних
> .py[co] без исходника? Отладка точно пострадает. Что-нибудь ещё?
Я. Уже полгода, каждый день проверяю. На домашней машине некоторые пакеты пересобраны таким
образом. Отладка не страдает, других проблем нет. Единственная
большая проблема - нужно знать что ты ставишь и зачем, причем основная тонкость не отсутствие
_исходника_, без него-то все работает на ура, основная тонкость pyc vs pyo. Если сервер "продакшн продакшн
и никакой отладки" то ставим pyo и все ОК. Если появляется отладка - то, похоже, придется ставить и pyc и pyo
в основном пакете.
--
WthBstRgrds -- Андрей Орлов --
--- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [devel][JT] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-23 6:37 ` [devel] " Andrey Orlov
@ 2004-02-23 7:32 ` Andrey Rahmatullin
0 siblings, 0 replies; 11+ messages in thread
From: Andrey Rahmatullin @ 2004-02-23 7:32 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
On Mon, Feb 23, 2004 at 09:37:54AM +0300, Andrey Orlov wrote:
> ЗЫ: Еще более загадочно, что ранее фигуровавшее обозначение pythonXY+1 таких
> вопросов не вызывало.
А в этом направлении полиси уже есть.
%
Главное ни в коем случае не делайте версию со знаком +. Тут может rpm
сглючить.
-- inger in devel@
%
--
WBR, wRAR (ALT Linux Team)
> Лечение -- сугубо организационное: не запускать vlock из-под mc
> из-под root, а лучше -- и mc из-под root.
<flame>
mc лучше не запускать вообще.
</flame>
-- ldv in community@
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* [devel] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-23 6:50 ` [devel] " Andrey Orlov
@ 2004-02-24 0:16 ` Mikhail Zabaluev
2004-02-24 5:01 ` Andrey Orlov
2004-02-24 11:18 ` Алексей Любимов
0 siblings, 2 replies; 11+ messages in thread
From: Mikhail Zabaluev @ 2004-02-24 0:16 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 4945 bytes --]
Hello Andrey,
On Mon, Feb 23, 2004 at 09:50:40AM +0300, Andrey Orlov wrote:
>
> > Нужно решить лишь такую задачу: если есть зависимость между модулями,
> > эта зависимость должна учитывать версию python ABI. Как этого можно
> > достичь, я писал.
>
> Увы, но синтаксис языка тоже менятся, не оставаясь до конца совместимым
> ни вперед, ни назад. Zope для версии 2.2 разражается кучей предупреждений
> и ввалится, при запуске с 2.3, причем исключительно из-за проблем синтаксиса.
Здесь ещё раз хочу предложить wrapper /usr/bin/python, который
позволит устанавливать версию с помощью переменной окружения
PYTHON_VERSION для любого отдельного приложения.
Alternatives, как вы понимаете, такой гибкости дать не может.
Нужно ли решать эту проблему с помощью вилки "ужесточение/усложнение"
("конфликтный" python vs "левый" python-weak), когда более элегантное
решение есть и уже отработано на других приложениях? Ей-богу, когда
пользователей зажимают в жёсткие зависимости и крюки, чтобы их обойти,
это может быть гораздо хуже, чем дать им возможность ошибиться,
запустив приложение не под тем python. Тем более, что это главным
образом проблема ПЕРЕХОДНОГО ПЕРИОДА в Sisyphus. Обеспечение
полностью безболезненного апгрейда для пользователей Sisyphus -- это
вообще не-задача.
> > Я думаю, можно полагаться на неявное обязательство разработчиков
> > Python не ломать ABI между микро-релизами.
>
> Я тоже думаю, только как я уже написал - дело не в ABI, а в синтаксисе.
Синтаксис тем более не меняется между микро-релизами.
> > По крайней мере, такое правило должно соблюдаться: если пользователь ставит
> > apt-get install python python-doc
> > он вправе расчитывать на наличие всех модулей, о которых написано в
>
> Соблюдается. Правда, в перспективе, скорее python, python-modules, python-doc.
> зависимость python / python-modules - временное решение.
Предлагаю сделать постоянным. Для любителей компактной установки
всё равно останется python-base и ручной выбор python-modules-*
> > > python-weak -- python с облегченными зависимостями,
> > > допускающий провести совместную установку со старой версий pythonX.Y
> >
> > Я чую ненужную сложность.
> > не будет установлен. Отпустите python-weak в пространство
> > невоплощённых идей.
>
> Не отпущу. Вам не мешает - мне нужно, некоторым другим - тоже. Кроме
> того, это работает.
Мне мешает любое отклонение от ожидаемого именования пакетов,
которое надо запоминать или разыскивать.
Аргумент "мне и некоторым другим нужно" от корифея-разработчика вызывает
нехорошие подозрения. Вспоминается панель управления GNOME 1.4,
80% которой повергали обычного пользователя в ступор.
Что можно сделать, если пользователь установил python-weak по недомыслию и
желает его сменить на нормальный python? Апгрейдится ли python-weak и
на что? Наконец, нужно ли всё это где-либо вне Sisyphus?
Если ответ на последний вопрос "нет", лучше убейте этот аппендикс
и уберите конфликт между python и legacy pythons. Те, кто используют
Sisyphus, смогут разобраться сами, иначе им не стоит использовать
Sisyphus.
> Установка новой версии командой apt-get install python приведет
> к сносу старой версии, из-за существующего между ними конфликта.
Меня тут озарило.
Нужно ввести как policy критерий использования тега Conflicts: тогда и
только тогда, когда есть конфликт по файлам либо совместная установка
пакетов _безусловно_ нарушает работоспособность системы или её
составляющих. Если вы используете Conflicts для каких-то других
целей, вы роете яму себе и другим.
> > > 6. Симлинки на головные модули пакетов, устанавливаемых
> > > многократно с специфичными версиями python должны управлятся посредством
> > > alternatives, что позволяет избежать ситуации, с запуском головного
>
> > Интересно, как вы этого добьётесь, если python и инструмент
> > устанавливаются раздельно и используют отдельные конфигурации
> > для alternatives (slave невозможен).
>
> Пока что я этого добиваюсь, так как все такие пакеты мои и являются частью питона,
> как например idle и pynche.
С трудом представляю. При установке python заводится slave на idle,
которого может не быть в системе?
Без slave возможен разнобой, когда python показывает на 2.2,
а idle на 2.3.
> > Не стоит. Python - скриптовый язык, и пусть модули сохраняют
> > скриптовый вид. Если нужна "компактность, компактность, компактность",
> > пользуйтесь zip-ованными архивами, которые поддерживает python 2.3
>
> Нужна не только компактность, но и быстродействие
И наличие .py рядом с компилированным кодом влияет на это как?
> а также некая степень
> защищенности от случайного вмешательства со стороны любителя "грязной"
> настройки.
Учим пользователя жить в его собственной системе? :)
Это настолько не в духе Unix, что я даже не знаю, что на это возразить...
--
Stay tuned,
MhZ JID: mhz@altlinux.org
___________
Military intelligence is a contradiction in terms.
-- Groucho Marx
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [devel] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-24 0:16 ` Mikhail Zabaluev
@ 2004-02-24 5:01 ` Andrey Orlov
2004-02-24 11:18 ` Алексей Любимов
1 sibling, 0 replies; 11+ messages in thread
From: Andrey Orlov @ 2004-02-24 5:01 UTC (permalink / raw)
To: ALT Devel discussion list
On Tuesday 24 February 2004 03:16, Mikhail Zabaluev wrote:
> Hello Andrey,
Ответ ушел мылом
--
WthBstRgrds -- Андрей Орлов --
--- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [devel] Re: A: Полиси ( я свел все воедино ) + FAQ
2004-02-24 0:16 ` Mikhail Zabaluev
2004-02-24 5:01 ` Andrey Orlov
@ 2004-02-24 11:18 ` Алексей Любимов
1 sibling, 0 replies; 11+ messages in thread
From: Алексей Любимов @ 2004-02-24 11:18 UTC (permalink / raw)
To: ALT Devel discussion list
Mikhail Zabaluev пишет:
>Hello Andrey,
>
>On Mon, Feb 23, 2004 at 09:50:40AM +0300, Andrey Orlov wrote:
>
>
>>>Нужно решить лишь такую задачу: если есть зависимость между модулями,
>>>эта зависимость должна учитывать версию python ABI. Как этого можно
>>>достичь, я писал.
>>>
>>>
>>Увы, но синтаксис языка тоже менятся, не оставаясь до конца совместимым
>>ни вперед, ни назад. Zope для версии 2.2 разражается кучей предупреждений
>>и ввалится, при запуске с 2.3, причем исключительно из-за проблем синтаксиса.
>>
>>
>
>Здесь ещё раз хочу предложить wrapper /usr/bin/python, который
>позволит устанавливать версию с помощью переменной окружения
>PYTHON_VERSION для любого отдельного приложения.
>Alternatives, как вы понимаете, такой гибкости дать не может.
>
!#/usr/bin/python22 или !#/usr/bin/python23
В первой строке скрипта.
Тем более, раз уж все договорились, что питон должен быть в массе своей
один, то незачем городить кучу инструментов для ничтожных задач. Они все
равно умрут от забвения...
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-02-24 11:18 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-22 19:32 [devel] A: Полиси ( я свел все воедино ) + FAQ Andrey Orlov
2004-02-22 21:40 ` [devel] " Mikhail Zabaluev
2004-02-22 22:18 ` Mikhail Zabaluev
2004-02-22 22:34 ` Dmitry V. Levin
2004-02-22 22:57 ` [devel] " Денис Смирнов
2004-02-23 6:37 ` [devel] " Andrey Orlov
2004-02-23 7:32 ` [devel][JT] " Andrey Rahmatullin
2004-02-23 6:50 ` [devel] " Andrey Orlov
2004-02-24 0:16 ` Mikhail Zabaluev
2004-02-24 5:01 ` Andrey Orlov
2004-02-24 11:18 ` Алексей Любимов
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git