[devel] new unmets

[Andrey Orlov]

On Tuesday 22 June 2004 21:01, Maxim Tyurin wrote:
> P.S. Так что с ним таки делать?

В FAQ /usr/share/doc/rpm-build-python есть _подробный_ ответ на этот вопрос.
Так как подозреваю что там может быть не самая последняя версия, то процитирую
сюда. Этот ответ уже несколько раз проходил в рассылке. Интуиция подсказывает,
что в вашем случае имеет место п.1 или 3. Предложение обратится за консультаций / помощью 
ко мне по прежнему в силе: разгребя грабли в Zope & rPAS я думаю, что любая проблема
в рамках текущей среды разрешима.

Кстати, в поиске Provides ошибки действительно есть. Т.е. они пофикшены в моей тестовой версии.

== cut ==
    
    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:

    Надо разбиратся с конкретными пакетами, которые провайдят эти дела иразбираться почему они не 
    встают. Типовой вариант один: автоматический поиск зависимостей нашел
    такие зависимости, которые не могут быть удовлетворены в принципе - напремер, на модули для макоса.
    
    Методы борьбы зависят от причин возникновения:
    
    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))).

    Иными словами, вы возвращаетесь к ситуации, которая была до введения
    полиси. Разумеется, т.о., ваш пакет будет ее нарушать, но это даст вам
    время решить проблемы одним из более правильных способов, изложенных
    выше
 == cut ==

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray на neural.ru, jid: cray на altlinux.org ---
----------------------------------------