[devel] QA: Unmets в питоновских модулях , как с ними боротся

[devel] QA: Unmets в питоновских модулях , как с ними боротся

[Andrey Orlov]

Hi!

Это письмо уже проходило по рассылке, но судя по тому, что цитаты из него
попрежнему помогают решать проблемы, его стоит запостить еще раз:

Должен заметить - данная инструкция позволяет быстро решить проблему.
== CUT ==
Q15: Unmets в питоновксих модулях, как с ними боротся?
    > 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 ---
----------------------------------------

Re: [devel] QA: Unmets в питоновских модулях , как с ними боротся

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Mon, May 24, 2004 at 01:40:37PM +0400, Andrey Orlov wrote:
> == CUT ==
> Q15: Unmets в питоновксих модулях, как с ними боротся?
>     > The following packages have unmet dependencies:
>     >   solfege: Depends: python2.3(gnome) but it is not installable
>     A15:
>     Надо разбиратся с конкретными пакетами, которые провайдят
>     эти дела и разбираться почему они не встают.
[...]
> 5. Наконец, есть плохой, неправильный, но очень быстрый способ
> решить проблему "временно": отключить поиск зависимостей:
> AutoReqProv: yes, nopython
> Requires: python-strict

Увы, пришлось лечить solfege-2.0.5-alt2 именно таким образом.
Я не питонист, да и пакет поддерживаю скорее "по доброй памяти".

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] QA: Unmets в питоновских модулях , как с ними боротся

[Andrey Orlov]

On Friday 18 June 2004 17:54, Michael Shigorin wrote:
> Увы, пришлось лечить solfege-2.0.5-alt2 именно таким образом.
> Я не питонист, да и пакет поддерживаю скорее "по доброй памяти".

Повесь багу на rpm-build-python. Иначе я забуду. 

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

Re: [devel] QA: Unmets в питоновских модулях , как с ними боротся

[Igor Tertishny]

>
>  4. Наверно, в поиске зависимостей и провайдес есть ошибки. В этом случае
>     нужно удалять зависимости или проставлять провайдес вручную:
>
>     %add_python_req_skip <ИМЯ_МОДУЛЯ>
>
>     Provide: python%__python_version( <ИМЯ_МОДУЛЯ> )
>

Со scribus сработал этот вариант. Спасибо за подсказку, я уж голову 
сломал... :-))

Re: [devel] QA: Unmets в питоновских модулях , как с ними боротся

[Andrey Orlov]

On Wednesday 23 June 2004 13:54, Igor Tertishny wrote:
> >
> >  4. Наверно, в поиске зависимостей и провайдес есть ошибки. В этом случае
> >     нужно удалять зависимости или проставлять провайдес вручную:
> >
> >     %add_python_req_skip <ИМЯ_МОДУЛЯ>
> >
> >     Provide: python%__python_version( <ИМЯ_МОДУЛЯ> )
> >
> 
> Со scribus сработал этот вариант. Спасибо за подсказку, я уж голову 
> сломал... :-))

Разумеется этот вариант сработал, но этот вариан - паллиатив и вы должны очень 
четко это понимать. Отключение системы автоматического определения зависимостей
- полное или частичное - это принципиально неверный шаг, шаг в сторону внезапной
потери работоспособности. Этот шаг допустим только в том случае, если:

 1. Вы точно знаете где возникает зависимость;

 2. Вы точно знаете, что зависимость будет либо удовлетворена другим способом,
либо никогда не понабдобится.

В противном случае, вы рискуете получить пакет который будет установлен, но не будет
работать. Причем - он может работать сегодня и не работать завтра. Он может
работать у вас и не работать у соседа.

К сожалению, я слишком часто наблюдаю в последнее время такое решение вопроса,
и я не думаю что это пойдет на пользу дистрибутиву.

Так что я рад, что у вас все получилось, но боюсь что выбранный вами способ решения - не
самый лучший и грозит серьезными проблемами в ближайшем будущем.

PS: Кстати, при любом из этих двух случаев лучше наложить патч на исходный код. Пожалуй,
единственная ситуация, которую сейчас не удаетс разрешить без skip-requires - это
удовлетворение внутримодульных зависимостей у модуля разрезанного на части. Это 
очень редкая ситуация, я ее видел только один раз у себя и слышал о еще одном
случае, в принципе ее возникновения я склонен считать результатом плохого дизайна
модуля, но, тем не менее, иногда хороший дизайн невозможен.

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

Re: [devel] QA: Unmets в питоновских модулях , как с ними боротся

[Igor Tertishny]

Что самое интересное, не находился модуль python2.3(scribus)... Вы правы, это 
не выход, но я пока другого не нашел. Буду еще думать. Может стоит вынести 
питоновский модуль из scribus  в отдельный пакет? Откровенно говоря, никак не 
пойму, что с ним делать.

%add_python_req_skip python2.3(scribus)
Provides: python%__python_version python2.3(scribus)

Я поступил вышеуказанным образом. Что еще интересно, остальные питоновские 
модули находятся автоматически.

Re: [devel] QA: Unmets в питоновских модулях , как с ними боротся

[Andrey Orlov]

On Wednesday 23 June 2004 14:32, Igor Tertishny wrote:
> Что самое интересное, не находился модуль python2.3(scribus)... Вы правы, это 
> не выход, но я пока другого не нашел. Буду еще думать. Может стоит вынести 
> питоновский модуль из scribus  в отдельный пакет? Откровенно говоря, никак не 
> пойму, что с ним делать.
> 
> %add_python_req_skip python2.3(scribus)
> Provides: python%__python_version python2.3(scribus)

Откуда вы это взяли?! Кришна, неужели я так написал в FAQ? ;)
Правильно - 

%add_python_req_skip scribus (специально сделано так, чбы можно было пересобрать
с другим питоном)

Provides: python%__python_version(scribus)

Кроме того, если я правильно понял проблему, то достаточно только одной (любой из) этих
кляуз. Причем. видимо лучше использовать вторую. Ваш модуль уже в инкоминге, я посмотрю его?

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

Re: [devel] QA: Unmets в питоновских модулях , как с ними боротся

[Andrey Orlov]

On Wednesday 23 June 2004 14:32, Igor Tertishny wrote:
> Я поступил вышеуказанным образом. Что еще интересно, остальные питоновские 
> модули находятся автоматически.

Я посмотрел scribus. Дело в том, python.find.prov провайдес sсribus не находит,
потому что его там нет. Иными словами, scribus python2.3(scribus) не провайдит:

%python
>>> import scribus
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named scribus
>>>

так что все вполне допустимо.

Я просмотрель исходники, насколько я понял, scribus - это некая утилита (не суть) слинкованная
с питоном, которая может использовать питон в качестве внутреннего скрптового языка, для работы
с которым она провайдит builtin модуль scribus - поправьте меня, если я не прав.

А раз так, то нужно ставить не provide, а skip - т.е. когда я писал про лушче в предыдущем письоме,
 я был неправ: 

%add_python_req_skip scribus  - вот это правильный выбор.

Теперь  вопросу о построении пакета. Не думаю, что имеет смысл прямо сейчас, но если
пакет будет развиваться, то в будущем стоит подумать о таком варианте.

В принципе, питоновские скрипты из него надо выносить. Во что-то типа 
scribus-module-<имя скрипта>. Наша полиси такой случай вообще-то не описывает (это в чистом
виде второй случай такого рода, правда, есть еще Zope - это третий, но там хоть проблемы сходные,
причины, формально, другие). Можно предложить что-то типа следующего:

1. Завести подпакет scribus - это собственно сам scribus;

2. Который провайдит что-то типа srcibus-core

3. Все скрипты к srcibus разбить либо по одному, либо пучками на подпакеты.

4. В каждом из них вписать

%add_python_skip_req scribus
Require: scribus-core

Последнюю операцию, насколько я понимаю, можно автоматизировать, 
но я этим некогда не пользовался.

Насчет именования пакетов - ну, я прям даже не знаю. Система именования питоновских
модулей к ним не применима, потому как по совокупности признаков они
питоновскими модулями не являются, хотя и написаны на питоне. Так что
стандартное 

"python" [<X> ". " <Y>] "-module-" <NAME> 

им не подходит. 

4all: Прошу считать вышеизложенное предложением для обсуждения. Так как такие
пакеты будут появлятся и дальше.

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