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

[Andrey Orlov <cray@neural.ru>]

[-- 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})