Имеем некий пакет, который содержит в себе некомпилированные скрипты на python (выполняются внутри отдельной программы, которая слинкована с python). Скрипты лежат в /usr/share/games/<имя пакета>/ При сборке этого пакета происходит следующее: Выгребаются все зависимости из этих скриптов, хотя они ничего снаружи не тянут и зависят исключительно сами на себя. В таком случае необходимо добавлять в этот же пакет provides для найденных в пакете модулях. Иначе получаем явный бардак - requires есть, а provides - нет ;-(
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, что бы не мешалось
