================================================================================

Часто задаваемые вопросы :

    Я первые несколько придумал сам, остальные буду добавлять по мере
    возникновения.
    
    Q1: Где можно взять текст данной Policy?
    
    A1: В каталоге /usr/share/doc/rpm-build-python хранится последняя актуальная
        версия полиси.
        
    Q2: Как внести изменения в Policy?
    
    A2: Отослать их на адрес python at packages.altlinux.ru. Они будут обсуждены
        действующими членами Python Team.
        
    Q3: Кто автор Policy и почему? Какова история ее возникновения?
    
    A3: Автор - комьюнити. Идея полиси возникла летом 2003-го года (cray, doc,
        ldv и др), когда некоторые основные идеи были согласованы, но в
        дальнейшем не развивалась - все что-то тихо клепали, но особого
        взаимного интереса не проявляли. Существенный вклад сделал Алексей
        Морозов, заставивший меня начать шевелится, и Алексей Любимов,
        заставивший меня увидеть некоторую проблему.
    
        Поддерживаю полиси я, Андрей Орлов, мантейнер пакета python & Zope. Я же
        обладаю (наверно) каким-то решающим голосом. Почему я? Потому что
        логично поручить это мантейнеру python. Будет другой мантейнер python -
        видимо, он же будет рулить и полиси. Почему решающим? Потому что должен
        же кто-то выбрать из двух стогов сена один ;), а я достаточно туп и
        ленив, чтобы :
        
            a)  Не делать лишних шагов;
        
            b)  Не вдаватся в многочисленные тонкости: лучше удовлетворительное
                решение сегодня, чем замечательное - через год (тем более, что
                через год оно так и так будет);
                
        По-моему это главное требование к решающему голосу, впрочем, по спорным
        вопросам я консультируюсь LDV, и, возможно, настоящий решающий голос
        все-таки принадлежит LDV, только я об этом не знаю.
        
    Q4: Я считаю что макрос такой-то и сякой-то, используемый при сборке
        "стандартного" модуля неудачный. К кому мне обратится?
        
    A4: К Алексею Морозову, макросы пишет он. Я рад, что нашелся человек,
        который это взял на себя, а заглянув в эти макросы, я подумал - что он
        знает, что делает.  Мне про макросы лучше не писать, результат может
        быть неадекватный (разве что в рамках п.QA2).
        
    Q5: Почему бы не сделать тоже самое на основе Distutils ?

    A5: Основная идея Distutils - собрать по некоторому универсальному
        конфигурационному файлу информацию об использумемой операционной
        системе и (в случае rpm) сгенерировать под нее спецификацию.
        Спецификация генерируется по некоторому "умозрительнному" темплейту.
        Пакет rpm-build-python добавляет в инсталляцию Distutils команду
        bdist_altrpm, выполняющую генерацию спецификации, соответствующей
        данной полиси, но ее лучше пока рассматривать как бета-версию (правда,
        я-то ей пользуюсь). К сожалению, использование Distutils не предполагает
        удобного способа поддержки пакета в рамках репозитория, так как нет
        технологичного способа сливать изменения, сделанные в setup.py
        разработчиками пакета и изменения, внесенные в него (и особенно -
        сгенерированную спецификацию) мантейнерами.
        
    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.  Файлы py, pyc, pyo при полной установке, кладутся точно в то
                место, куда бы они легли при обычной установке, никакого
                специального выделения файлов py (в каталог /usr/share/doc,
                /usr/src, еще куда-либо) не будет: это создаст проблемы.
                
            3.  Видимо, пакеты будут разрезаны на python-<MODULE> &
                python-<MODULE>-src, при этом python-<MODULE> содержит файлы
                pyo и (или) pyc, а ...-src - файлы py.
                
            4.  Что касается включение файлов pyc или pyo, то возможны три
                варианта:
            
                    - Включение обеих (сейчас этот вариант представляется
                    - единстенным возможным);
                    
                    - Включение на стадии сборки одного из типов файлов
                        (требует спеиальных макросов, что Алексей обещает
                        сделать, или ручной работы, также требует патчить
                        питон);
                        
                    - Включение политики установки по аналогии с
                        %_install_langs (я стою за этот вариант, так как у
                        потребителя остается выбор, который он может сделать
                        в зависимости от своих потребностей, но это требует
                        патчить не только python, но и rpm;
                        
            5.  Зависимости ставятся только на основной пакет т.е. 
                python-<MODULE>, пакет с исходными текстами используется
                только разработчиками или теми, кому нужна "грязная"
                настройка (ставим -src, редактируем один из файлов, все
                остальное сносим, один файл оставляем, кажется это можно
                автоматизировать, но я не пробовал);
                
            6.  Никогда не удаляются *py c головными модулями.
                                
        Данный ответ дан на основе личных убеждений, разговоров с Алексеем и
        писем в рассылке.
        
    Q11: Когда будет python24 и где его взять?
    
    A11: До выхода релиза - только в дедале. Сейчас его там нет ;), но по
        завершении возни с переходом на новую схему сборки я его соберу.
                
    Q12: Когда появится Zope27?
    
    A12: Offtopic! offtopic! Уже вышел, к тому же.

    Q13: Как собирать пакеты под Zope?
    
    A13: Пакеты под Zope - это пакеты под Zope. К пакетам под python имеют
        довольно отдаленное отношение. Главный сборщик пакетов под Zope,
        сейчас, Генадий Ковалев, мантейнер Plone, наверно его опыт будет вам
        более полезен чем мой, тем более, что то что мы с ним делаем мы
        между собой согласовали.
        
    Q14: Если апгрейд модуля/приложения требует python = 2.3, почему бы не
        иметь в дистрибутиве python23, который благополучно вытянется, если
        он такое предоставляет?
        
        У нас уже организовано так несколько семейств пакетов, стоит ли
        здесь изобретать велосипеды?

    A14:Текущая схема с несколькими семействами пакетов обладает рядом
        недостатков, основной из которых - невозможность "прозрачного" для
        потребителя перехода с одной версии питона на другую: гипотетический
        потребитель вынужден составить список всех пакетов одной версии,
        аккуратно их снести и поставить вместо них пакеты другой версии,
        причем зависимость на python = 2.3 помогает в этом очень слабо : в
        лучшем случае образуется разрозненная установка смеси двух питонов,
        которая не особенно работоспособна, в худшем - ручной апгрейд.
        
        Ситуация усугубляется тем, что мы разрезали python на мелкие
        подпакеты.
        
        В тоже время, при новой схеме семейств пакетов, всегда есть только
        один основной пакет - python-*-X.Y - и при появлении python-*-X.Y+1
        (плюс - знак арифиметической операции, а не элемент названия) его
        апгрейд будет выполнен в обычном порядке. Подробнее об этом можно
        прочитать в notes/Names.txt.
        
        Да, и по поводу велосипедов: я считаю, что наш велосипед лучше,
        поэтому стоит.
        
    
    Q15:
    > The following packages have unmet dependencies:
    >   solfege: Depends: python2.3(gnome) but it is not installable
    >            Depends: python2.3(gobject) but it is not installable
    >            Depends: python2.3(gtk) but it is not installable
    >            Depends: python2.3(mpd) but it is not installable
    >            Depends: python2.3(pango) but it is not installable
    >            Depends: python2.3(soundcard) but it is not installable
    >            Depends: python2.3(src) but it is not installable
    
    A15:

        Надо разбиратся с конкретными пакетами, которые провайдят эти дела и
        разбираться почему они не встают. Типовой вариант один:
        автоматический поиск зависимостей нашел такие зависимости, которые
        не могут быть удовлетворены в принципе - напремер, на модули для
        MAC-оса.
        
        Методы борьбы зависят от причин возникновения:
        
        1. Зависимости порождаются файлами, которые не используются пакетом
        (встречается).
        
            Решение: прибить такие файлы
        
        2. Зависимости порождаются тестовыми модулями.
        
            Решение: вынести тестовые модули в отдельный подпакет
            (python-module-SOMETHAT-test) и поставить на нем AutoReqProv:
            nopython. Еще вариант - стереть.
        
        3. Зависимости порождаются условными конструкциями:
        
        
            Пример такой конструкции:
        
                if EXPR : import MACOSMODULE
                
            Большая часть таких проблем не возникает (я научился это
            отлавливать, подробности в доке), но если вдруг возникли - решений
            два: пропатчить модуль, чбы исключить такой код, или явно исключить
            зависимость указанием в спеке выражения:
            
                %add_python_req_skip <ИМЯ_МОДУЛЯ>
        
        4. Наверно, в поиске зависимостей и провайдес есть ошибки. 
        
            В этом случае нужно удалять зависимости или проставлять
            провайдес вручную:
        
                %add_python_req_skip <ИМЯ_МОДУЛЯ>
        
                Provide: python%__python_version( <ИМЯ_МОДУЛЯ> )
        
            После этого, желательно повесить баг на пакет rpm-build-python с
            указанием пакета и проблемной зависимости.

        5. Можно попробовать "собирать как раньше".
        
            Это плохой, неправильный, противоречащий полиси, но очень
            быстрый способ решить проблему "временно": отключить поиск
            зависимостей:

                AutoReqProv: yes, nopython 
                
                Requires: python-strict
                
            По зависимости python-strict вытянется "стандартная установка
            python", а поиск зависимостей будет отключен. Помните, что в
            этом случае предполагается что все необходимые зависимости вы
            проставите сами (скорее всего, они у вас уже стоят, только на
            сами пакеты, а не на автоматически найденные Provides, только
            обратите внимание еще и на то, что для подавляющегео большинства
            пакетов-модулей изменилось имя (например MySQL-python ->
            python-module-MySQLdb))).

            Иными словами, вы возвращаетесь к ситуации, которая была до
            введения полиси. Разумеется, т.о., ваш пакет будет ее нарушать,
            но это даст вам время решить проблемы одним из более правильных
            способов, изложенных выше. Я должен подчеркнуть, что пакеты с
            зависимостью на python-strict - временное решение и в будущем
            обязательно должны быть пофиксены.
           

    Q16: Если установлено только python-base-2.3.3-alt9 и
        python-relaxed-2.3.3.alt9, python.prov.py не работает:
        rpm-build-python должен требовать python2.3(__future__);
    
    A16: Это был текст ошибки, которая уже исправлена. 
    
        Тем не менее, исправлена она совсем не так, как предлагалось,
        поэтому требуется данное разъяснение.
    
            1. Я не могу вставить в rpm-build-python требование любой
                конкретной версии python - а Require: python2.3(__future__)
                это именно такое требование. Не могу, потому что сборка
                может идти с любым питоном.
                
            2. Я не хочу вставлять в rpm-build-python требование установки
                python вообще - т.к.  такое требование приведет к
                обязательной установке питона в рамках сброчно среды ни в
                чем ни повинным людям. Их отношение к этому я предвижу, по
                аналогии с тем, что лично меня раздражет необходимость
                регулярного обновление перла для сборочной среды, который
                мне на хрен не нужен - я не нем не пишу так давно, что даже
                его забыл.

            Замечание [Алексей Турбин, 2007-03-18]: вообще-то в базовой
            сборочной среде присутствует только пакет perl-base, в развернутом
            виде занимающий 3.5M.  Кроме того, зависимость на perl-base
            присутствует в пакете basesystem.

        И, понимая то, что такие тендеции нарастают, я с ужасом думаю о
        сборочной среде содержащей все, от перла до tcl и от фортрана до
        ады. Я считаю правильным другой путь и им воспользовался.
        
        Я ввожу в полиси два постулата:
        
            1.  Сборка любого питон-пакета должна проводится в средде,
                содержащей python-devel;
            
            2.  В отсутствие каких-либо компонент python, необходимых для
                работы, скрипты из пакета rpm-build-python завершаются
                коррекно, но ничего не делают.

            Замечание [Алексей Турбин, 2007-03-18]: второй подход чреват
            неприятными последствиями.  Поиск питоновских зависимостей
            становится чувствительным к [ -x /usr/bin/python ] и наличию
            необходимых модулей.  Можно даже представить себе ситуацию,
            когда вследствие этого отключается поиск provides, а это уже
            чревато unmet'ами в репозитарии.  В целом второй подход слишком
            ненадежен, тогда как первый подход, действительно, требует внесения
            лишних пакетов в базовую сборочную среду.  Я предлагаю следующее
            решение: нарастить python-base модулями, достаточными для работы
            python.req.py и python.prov.py (на самом деле не хватает всего трех
            файлов - parser.so, token.py и symbol.py); и добавить зависимость
            на такой python-base в rpm-build-python.  Наличие python-base
            в базовой сборочной среде не должно никого сильно расстроить,
            поскольку python-base в развернутом виде занимает чуть больше 2M.
            Зато rpm-build-python будет работать надежно.

        Собственно исправление ошибки свелось к обеспечению выполнения
        условия-2. Я это проверил, на паре пакетов - они действительно
        раньше падали при сборке, тогда как теперь не падают.
                    
        Тем, кому интересны технические детали - все необходимые зависимости
        вынесены из модули rpm-build-python в модуль python-devel или
        python-base (который требует python-devel), тогда как в скрипты
        rpm-build-python добавлены обработчики аварийных ситуаций,
        завершающие скрипты с кодом SUCCESS.

    Q17:    Почему бы не убрать умолчание на опцию python в AutoReqProv? 
        Пусть там стоит nopython, все пакеты собираются как раньше и
        работают, а особо продвинутые пользователи ставят опцию python и
        разбираются с зависимостями?  Тогда все старые пакеты работа ли бы,
        а новые - собирали бы уже правильно и переход не был бы так
        болезнен?
        
    A17:    Самое неприятное - это не поможет. До перехода на новую
        python-policy, поиска зависимостей не было, и все зависимости на
        __пакеты__ были проставлены вручную. Например, зависимость на пакет
        python. Но, пакет python сильно изменился
        - в частности, был разрезан на куски. И поэтому больше не провайдит
        того, что провайдил тогда. Т.о. стали возможны два варианта:
        
            1.  Обязательный автоматический поиск зависимостей, который либо
                находит все нужные зависимости, либо дает ошибку. В
                результате мы получаем либо багрепорт, либо работающий
                пакет.
                
            2.  Просьба к мантейнерам пересобрать и протестировать пакеты.
                Мало того, что такая просьба может быть проигнорирована, в
                силу отсутствия мантейнера, так еще и сама работа тяжелая и
                может приводить к ошибкам, в результате чего мы получаем
                репозиторий, полный пакетов с неизвестной
                работоспособностью.
                
                Существует, правда, упрощенное решение в поиске зависимостей
                - поставить зависимость на python-strict. Это более-менее
                гарантирует работоспособность, но не дает полной гарантии;
                
        Я выбрал первый вариант, как более продуктивный - так как мы всегда
        можем быть уверены, что пакеты в репозитории работают, если
        ставятся.
        
        Тем не менее, предложенный вариант также имел место. В течении
        полугода было так, как вы предлагаете, и только после нескольких
        обращений разработчиков с просьбой включить автоматический поиск
        зависимостей, а также нескольких явных траблов с
        неработоспособностью это изменилось.
        
    Q18:    Почему в перле не возникает таких проблем?
    
    A18:    Не знаю. Осмелюсь предположить, что просто с перлом
        нет ситуации переходного переиода, и когда переходный период закончится
        - у нас тоже не будут возникать проблемы. Во всяком случае, в рассылке
        иногда проскакивают репорты для perl,  с проблемами, сходным с
        нашими. Но они идут не так густо и относятся, преимущественно, к
        вновь добавляемым модулям.
        
        В то же время, хотелось бы отметить, что perl, особенно в части работы
        с модулями, совершенно другой язык по тому, как его принято использовать
        в приложениях.    

    Q19:    Почему мы ставим зависимостть на python-devel = 2.3, а не на
        python-devel ?
    
    A19:    Мы ставим зависимость на python-devel = 2.3, т.е. с указанием
        мажорной и минорной версии, т.к. это принятая в альтлинуксе практика
        в течении по крайней мере последних полутора лет - это не я
        придумал.
        
        В то же время, отказ от явного указания версии, из-за ряда проблем с
        apt или каких-то иных причин, приводит к тому, что пакет либо не
        пересобирается вообще, либо, что значительно хуже, пересобирается с
        альтернативным питоном (например, при наличии в репозитории,
        используемом сборочной средой двух и более сборок одного питона,
        такая ситуация, как показывает практика, типовая после размещения
        новой сборки). Такой пакет пересобранный с альтернативным питоном
        оказывается полностью работоспособен, но не полностю функционален
        (например, вместо зависимости python2.3(some) провайдит
        python2.2(some), которая конечно работает - но на хрен никому не
        нужна), в результате возникают unmets и неработоспособность десятков
        других пакетов, что вызывает понятные нарекания.
        
        Возможный выигрыш от того, что без указания такой зависимости сборка
        всегда будет происходит с последним имеющимся питоном, на самом
        деле, оборачивается проигрышем: известна масса случаев, когда при
        пересборке со сменой минора пакет терял работоспособность из-за
        изменения в синтаксисе python. Наглядные примеры - None, которая
        став встроенным объектом в 2.3 (утеряна возможность присваивания),
        полностью разрушила работу Zope и ряда других пакетов, введение
        обязательости указания кодировки. Про кошмар с изменением API
        модулей я просто промолчу. Я понимаю, что не надо так писать, но и
        вы поймите - так пишут. И не всегда дело мантейнера исправлять такие
        ляпы в программировании.
        
        Таким образом, только мантейнер может решить что пересборка пакета с
        новым питоном необходима и возможна, и только мантейнер может
        выполнить необходимые проверки.  Никакой автоматизации здесь быть не
        может, если мы хотим иметь работоспособные пакеты.
        
        Таким образом, длительная практика сборки пакетов доказала
        необходимость указывать номер версии, по крайней мере до минорной. 
        Дальнейшее указание можно считать излишним (есть один пример, когда
        смена субминора изменила питон настолько, что один из пакетов
        перестал работать, но, это все-таки единичный случай, тогда как
        проблемы при смене минора - массовое явление).
        
    Q20:    Почему нет пакета python-devel, но python-devel провайдится
        пакетом с дурацким названием python-dev?  Почему нужно ставить
        зависимость именно на python-devel, а не на python-dev?
        
    A20:        
        Точнее, на python-devel = 2.3. Если бы мы создали пакет
        python-devel, то он бы имел Provides: python-devel = 2.3 и
        python-devel = 2.3.4.  Хотя rpm нормально отрабатывает такую
        ситуацию, с ней не справиляется apt и по Requires: python-devel =
        2.3 не находит ничего. Поэтому python-devel пришлось сделать
        виртуальным пакетом, а сам пакет переименовать во что-то другое.
        Если вам не нравится название python-dev - предложите свое. Я честно
        говоря в тот момент просто устал разруливать недокументированные
        траблы apt и на выдумывание названия сил уже не было. Наверно,
        python-build был бы лучше.
        
        (Я сейчас уже не очень точно помню, но кажется проблема была именно
        с apt, а не с rpm, впрочем, не так важно с кем).
        
        Собственно, на python-dev зависимость поставить нельзя по той же
        причине: это не сработает, так как python-dev = 2.3 не провайдится,
        а ставить зависимость на python-dev = 2.3.4 не имеет смысла -
        необправдано сильное требование.
       
    
    Q21:    У меня есть пакет, в котором поиск зависимостей находит модуль
        karamba (kiki, etc), но я не знаю где его взять! Такого модуля нет,
        но все работает!
        
    A21:   Есть, но вы его не видите. Дело в том, что в данном случае вы имеете
        дело не с самим питоном, а с ембеддед питоном, который может отличатся
        от обычного питона, в частности, дополнительными builtin - модулями (см. Q22).
        
        Есть единственный правильный способ борьбы с этим - скипнуть эту зависимость,
        указав:
        
            %add_python_req_skip <имя модуля>,
            
        например:
        
            %add_python_req_skip karamba                    
        
        Это требует определенного интеллекта от мантейнера, но неизбежно. Решить
        это автоматически на уровне отдельного пакета невозможно, а вопрос о
        решении этого на уровне репозитория в целом пока не продуман.
        
    Q22:    Что такое builtin модули? Почему я его нигде не могу найти?
    
    A22:    Builtin - это модуль, встроенный внутрь ембеддед интерпретатора, в виде
        питоновских скриптов не может быть по определению. Кроме того, ни один 
        скрипт запущенный без именно этого ембеддед интерпретатор никогда и никаких
        образом не может получить доступ к этому модулю. Единственный способ
        решить проблему в этом случае - это поставить %add_python_req_skip и поствить
        явную зависимость на указанный ембеддед интерпретатор. В принципе, это едва ли
        не единственный случай, когда add_python_req_skip не является костылем, а есть
        единственно верное решение. 
        
        Если вы собираете пакет с embedded питоном, то неплохо получить список
        таких модулей. В этом вам может помочь следующий код (not tested):
        
            import sys
            
            print sys.builtin_module_names
            
        Этот код должен быть расположен внутри модуля, импортируемого
        встроенными интерпретатором, после его импорта вы получите список
        встроенных модулей на stdout и вам останется только скопировать его в спек.
        
        Разумеется, если у данного интерпетатора нет доступного stdout - задача серьезно
        осложняется.
    
    Q24:    Мой пакет содержит примеры и тестовые модули, я не хочу выделять
        их в отдельный пакет, но поиск зависимостей находит в них
        зависимости, которые не могут быть удовлетворены, потому что это
        примеры!
        
    A24:    Лучше всего их вынести в отдельный пакет, ибо нафига? Нужно двоим - страдают
        все. В то же время, решение есть.
        
        Поиск зависимостей просматривает не все файлы, а только те, которые
        лежат в директории %_findreq_topdir, за исключением
        перечисленных в макросе %_findreq_skiplist. Изменить эти макросы
        можно макросами set_findreq_topdir, set_findreq_skiplist,
        add_findreq_skiplist, которые описаны в документации на rpm. Ее на
        самом деле стоит прочитать, до того, как задавать вопросы о
        python-policy.

    Q26:    Мой пакет ставит модули в каталог /usr/lib/mypackage, и
        использует их только сам. Но поиск зависимостей находит в этих
        модулях зависимости на их же самих, в то время как эти модули не
        провайдятся (не входят в python-path), и из-за этого возникает
        unmets. Что делать?
        
    A26:    Хорошего решения, на самом деле, нет. В данный момент, общей практикой
        является указание %add_python_lib_path, в котором перечисляются все такие
        каталоги. Это не очень хорошее решение, так как модуль может быть недоступен
        другим приложениям без специальной настройки этого приложения. В принципе,
        этого надо избегать, хотя это не всегда возможно. Если модулей относительно
        немного - можно написать длинный add_python_req_skip. Тоже вариант,
        хотя и не самый простой. Чбы упростить последнюю задачу, можно воспользоваться
        командой:
        
            find <ПУТЬ К КАТАЛОГУ> | /usr/lib/rpm/python.req.py | sort | uniq

        которая выведит список всех зависимостей, нужных скриптам в указанном
        каталоге, или командой:
        
            RPM_PYTHON_LIB_PATH=<СПИСОК ПУТЕЙ К ДОПОЛНИТЕЛЬНЫМ КАТАЛОГАМ С МОДУЛЯМИ>

            (пути в списке разделяются пробелом)
            
            export RPM_PYTHON_LIB_PATH
            
            
            find <ПУТЬ К КАТАЛОГУ> | /usr/lib/rpm/python.prov.py | sort | uniq

        которая выведит список зависимостей. Вопрос дальнейшей автоматизации решается.
        
    Q27:    Как создать питоновский подпакет внутри другого, не питоновского пакета?        
        
    Q28:    Я хочу разбить модуль на две подпакета, только одна из которых
        содержит файл __init__.py, но искалка Provides находит только зависимости из
        одного пакета (в который входит __init__.py). Что делать?
        
    A28:    Нужно воспользоваться макросом python_module_declare <PATH>, где
        <PATH> - путь к каталогу содержащему файл __init__.py :
        
            python_module_declare /usr/lib/python2.3/email/
            
        Тогда поиск Provides для любого подпакета будет считать, что он
        обнаружил в каталоге <PATH> файл __init__.py, а для пакета, в
        который включена такая декларация автоматически добавится
        зависимость на модуль, соответствующий пути <PATH>;
        
        (в текущей версии макрос python_module_declare может не работать)
        
    Q29:    Что такое иерархическая зависимость?                    
    
    A29:    Иерархическая зависимость - это зависимость на модуль, вложенный
        внутрь другого модуля. Такая зависимтость записывается как :
        
            "python" <N> "." <M> "(" <NAME> [ "." <NAME> ] * ")"
            
        И порождается синтаксической конструкцией вида :
        
        
            "import" " " <NAME> [ "." <NAME> ]*
            
        Имеющий смысл "импортировать модуль NAME (2) из модуля NAME (1)".
        
    Q30:   Почему конструкция from <MODULE> import <NAME> не порождает
        иерархическую зависимость?
        
    A30:    Потому что в этой конструкции <NAME> не обязательно
        соответствует модулю - т.е. файлу (каталогу), а может
        соответствовать любому имени, определенному в модуле MODULE. Для
        языка Python не существует способа составить полный список таких
        имен до исполнения программы (хотя бы потому, что их список может
        изменятся в процессе выполнения программы произвольным образом).

     Пока что у меня других вопросов не возникло, так что присылайте.
        


Это python faq, а не полиси. Проблема в том, что если автоматический поиск не находит
модуль, то и питон этот модуль, скорее всего, не найдет. Ставить один из выше приведенных
операторов имеет смысл только в том случае, если вы стопудово уверены, что имеете
дело с одним из тех редких случаев, когда это рекомендовано в FAQ. В остальных случаях
стоит поискать проблему в вашем пакете. Типичный случай - модуль импортируется из того
участка кода, который не вызывается при ваших тестах, и этот модуль оттуда действительно недоступен.

Пример:

site-packages/a
site-packages/a/b
site-packages/a/b/test.py (содержит import b)
site-packages/a/b/__init__.py
site-packages/a/__init__.py (содержит import b)

Вот в такой ситуации модуль a полностью работоспособен (т.е. python -c "import a" отрабатывает без ошибок),
но в нем лежит (не откуда не вызываемый) файлик test.py, который __не__ работоспособен, так
как не видит (не может видить), в общем случае, подмодуль b. И именно он порождает спорную зависимость.

Я такие файлы обычно так или иначе удаляю из пакета.... У вас может быть и другой случай, некоторые из них описаны
в FAQ. 

В любом случае, если %add_python_req_skip хоть как-то обусловлено, то  %py_provides - это точно только для тех, кто знает,
что делает.

================================================================================
