From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Andrey Orlov To: ALT Devel discussion list Date: Mon, 24 May 2004 13:40:37 +0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Message-Id: <200405241340.37717.cray@neural.ru> Subject: [devel] QA: Unmets =?koi8-r?b?1yDQydTPzs/X08vJyCDNz8TVzNHI?= , =?koi8-r?b?y8HLINMgzsnNySDCz9LP1NPR?= X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2004 09:40:44 -0000 Archived-At: List-Archive: List-Post: 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 --- ----------------------------------------