1. 
> Имеем некий пакет, который содержит в себе некомпилированные скрипты на 
> python (выполняются внутри отдельной программы, которая слинкована с python). 
 
Такие программы - очень большая проблема в рамках python-policy, я не давно 
писал об этом в рассылке. К сожалению, разбиратся можно только с конкретными 
пакетами, с некоторыми - можно дать лишь общие ответы. 
 
2.  
> Выгребаются все зависимости из этих скриптов, хотя они ничего снаружи не 
> тянут и зависят исключительно сами на себя 
 
Такого быть не должно. Это проверялось. Нужен конкретный пакет, что бы это 
отследить & исправить, если это действительно так. Самоудовлетворямые 
зависимости не репортятся - в поиске зависимостей есть специальная логика для 
этого. Возможно, вы не точно сформульровали описание проблемы или она была вами 
неправильно интерпретирована. 
 
3. 
> Скрипты лежат в /usr/share/games/<имя пакета>/ 
> таком случае необходимо добавлять в этот же пакет provides для найденных в 
> пакете модулях. Иначе получаем явный бардак - requires есть, а provides -  
> нет ;-( 
 
Нет проблем - %add_python_lib_path, подробнее см. доки. Но __в_принципе__ такое 
размещениее файлов - death by design, и допустимо только для пакетов масштаба 
Zope. 
 
 
ЗЫ: честно говоря, возможно лучше для таких пакетов отключать поиск 
зависимостей для python - потому что это не питон.   
 

1. Это python, ибо он и только он embedded в vegastrike
2. пример можно посмотреть в пакете vegastrike-data. %add_python_lib_path не
работает.

Ошибка reopened и submited еще раз.

(In reply to comment #2) 
> 1. Это python, ибо он и только он embedded в vegastrike 
 
 
Это не совсем питон. Это ембеддед питон. Отличие в том, что у него могут 
быть другие пути и другой список __builtins__ модулей. Поэтому  
provide от vegastrike вообще говоря не гарантирует что этот модуль подойдет 
для python, точно также, зависимость найденая в модулях vegastrike  
в общем случае не может быть удовлетворена модулями питона. Это очень большие 
грабли, правда, в настоящий момент они не очень актуальны. Я буду это 
решать - хотя сейчас плохо представляю себе как 
 
 
> 2. пример можно посмотреть в пакете  
> vegastrike-data.  
 
> %add_python_lib_path не работает. 
 
Странно. Уже второй раз о таком слышу, как же он 
у меня-то везде работает? Я посмотрю. Не уверен, 
что в пакете эта кляуза осталась - можете написать 
что именно вы писали в %add_python_lib_path? 
 
 
> Ошибка reopened и submited еще раз. 
 
Теперь, когда указано что это за пакет - принято. 
 
 

ну собственно тогда нужно автоматом отключать поиск зависимостей.

Хотя, я все-таки считаю что зависимости типа:
python2.3(_socket)  
python2.3(_weakref)  
python2.3(binascii)  
python2.3(fcntl)  
python2.3(math)  
python2.3(md5)  
python2.3(operator)  
python2.3(pcre)  
python2.3(readline)  
python2.3(regex)  
python2.3(select)  
python2.3(string)  
python2.3(struct)  
python2.3(termios)  
python2.3(time)  
python2.3(zlib)

Наверное правильные.

Как вариант можно сделать так, что бы Provides из пакета и Requires из этого же
пакета друг друга не хотели ?

Т.е. - убираем все что есть в Provides и Requires одинакового.

Да, про то что написано в макросе - есть в другой баге.

(In reply to comment #4) 
> ну собственно тогда нужно автоматом отключать поиск зависимостей. 
>  
> Хотя, я все-таки считаю что зависимости типа: 
> python2.3(_socket)   
 
 
 
> python2.3(_weakref)   
> python2.3(binascii)   
> python2.3(fcntl)   
> python2.3(math)   
> python2.3(md5)   
> python2.3(operator)   
> python2.3(pcre)   
> python2.3(readline)   
> python2.3(regex)   
> python2.3(select)   
> python2.3(string)   
> python2.3(struct)   
> python2.3(termios)   
> python2.3(time)   
> python2.3(zlib) 
>  
> Наверное правильные. 
 
Разумеется, из провайдит python-modules 
> Как вариант можно сделать так, что бы Provides из пакета и  
> Requires из этого же 
> пакета друг друга не хотели ? 
>  
> Т.е. - убираем все что есть в Provides и Requires одинакового. 
 
Смертельно. Т.е. из пакета, скажем, python-modules пропадет половина 
provides, из-за того, что эти провайдес не только провайдятся но еще  
и используются пакетом? А вот удалять их из Requires - просто нет смысла, 
они же провайдятся. 
 
 
> Да, про то что написано в макросе - есть в другой баге. 
 
Извините, не нашел. Если можно - продублируйте на python@neural.ru,  
если помнитие - просто не хочется тратит время на поиски. Если не  
помните - хрен с ним, так разберусь. 
 
 

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

(In reply to comment #5)
> (In reply to comment #4) 
> > ну собственно тогда нужно автоматом отключать поиск зависимостей. 
> > Как вариант можно сделать так, что бы Provides из пакета и  
> > Requires из этого же 
> > пакета друг друга не хотели ? 
> >  
> > Т.е. - убираем все что есть в Provides и Requires одинакового. 
>  
> Смертельно. Т.е. из пакета, скажем, python-modules пропадет половина 
> provides, из-за того, что эти провайдес не только провайдятся но еще  
> и используются пакетом? А вот удалять их из Requires - просто нет смысла, 
> они же провайдятся. 

Дело в том, что тут никто не провайдит то что хочет этот пакет.

Т.е. - он бы вроде как и должен провайдить, но не может.

>  
>  
> > Да, про то что написано в макросе - есть в другой баге. 
>  
> Извините, не нашел. Если можно - продублируйте на python@neural.ru,  
> если помнитие - просто не хочется тратит время на поиски. Если не  
> помните - хрен с ним, так разберусь. 

Лучше прямо здесь. Вот что у меня сейчас написано в спеке:

%add_python_lib_path %gamesdatadir/%oname/modules/ %gamesdatadir/%oname/bases/
%gamesdatadir/%oname/modules/builtin/ %gamesdatadir/%oname/modules/stub

%add_python_req_skip Base Briefing Director VS faction_ships dynamic_mission
launch mission_lib vsrandom fixers explore quest

Соответственно модули (например faction_ships) лежат прямо в вышеперечисленных
каталогах.

Да, я опять возвращаю blocker, ибо собирать подобные пакеты в такой ситуации,
простите - просто невозможно. Я убил фактически весь день на то, что должны были
делать (и делали раньше, или наоборот - не делали, но все работало) скрипты.

(In reply to comment #6)
> Я не считаю его блокирующим, так как в FAQ указано несколько способов 
> решения проблемы. 

Надо туда добавить пункт "переписать все на Ruby".

Коль подход такой ;-)

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

Мантейнерство сильно отличается от разработки, и, то, что у меня случайно
попался пакет содержащий скрипты на python - не означает, что я обязан владеть
pyhton в полной мере для решения проблем (в большинстве своем - совершенно не
нужных), с зависимостями. И тем более - делать огромную массу ручной работы по
выискиванию того, кто в списке верен а кто нет.

 
> Андрей, я просто к тому веду, что надо жизнь другим мантейнерам максимально 
> облегчать а не максимально усложнять. Собственно чего и добиваюсь. 
 
Антон, я очень хорошо это понимаю и добиваюсь того же самого, хотя это 
не всегда очевидно. Переходный период неизбежно несет некоторые трудности, 
вызванные как несинхронностью работы команды так, безусловно, и моими 
собственными ошибками / недодумками. Именно поэтому из всех возможных 
путей перехода я выбрал тот, на котором граблей меньше всего. Мы понему 
и идем. Я понимаю, что вам иногда кажется что лучше было бы пойти к  
цели другим путем - я вариантов видел уже много и я обдумал их еще год 
назад. Граблей на них значительно больше и они страшнее: здесь 
отдиагностированные траблы при сборке - там не работающие пакеты. Я не буду 
вдаватся в подробности - это долго - но просто поверь мне, все что предлагалось 
за последние два месяца либо было сделано раньше, либо было обдумано и 
отвергнуто уже очень давно. Тот путь по которому мы идем - оптимален.  
 
И я всеми силами стараюсь его всем облегчить, даже ценой некоторых своих 
собственных проектов: я всех кто обращается консультирую, каждому стараюсь 
помочь. К сожалению, очень многих приходится переубеждать ;). 
 
> Мантейнерство сильно отличается от разработки, и, то, что у меня случайно 
> попался пакет содержащий скрипты на python - не означает, что я обязан 
> владеть 
> pyhton в полной мере для решения проблем (в большинстве своем - совершенно не 
> нужных), с зависимостями. И тем более - делать огромную массу ручной работыпо 
> выискиванию того, кто в списке верен а кто нет. 
 
Конечно. Мы что-нибудь придумаем. Просто в текущей версии не придумалось - и 
приходится использовать заранее заготовленную заплату, о которой написано в 
FAQ. 
 
 

Есть ли прогресс ?

На живого маинтейнера...

(In reply to comment #11)
> На живого маинтейнера...

Вы можете объяснить о чём речь-то тут шла? На примере конкретного пакета?
Учитывая тот факт, что оба спорщика -- фактически уже не разработчики.

Никто не отозвался. Выброшу от греха подальше.

closed, что бы не мешалось