8211 2005-10-13 19:52:54 +0400 Неверная зависимость пакета hal 2012-03-16 13:58:06 +0400 1 1 4 Development Sisyphus hal unstable all Linux CLOSED FIXED P2 blocker --- 1 php-coder rider gns inger ktirf rider sbolshakov qa-sisyphus oldest_to_newest 31836 0 php-coder 2005-10-13 19:52:54 +0400 Лишняя, как мне кажется, зависимость на openmotif-demos. Этот пакет "contains the Motif demo applications". Исходя из этого и просмотрев список файлов в пакете я пришел к выводу, что hal'у оно не нужно. Пожалуйста, удалите лишнюю зависимость.. 31837 1 ktirf 2005-10-13 20:01:19 +0400 Неясно, зачем hal требует openmotif вообще. 31838 2 php-coder 2005-10-13 20:18:27 +0400 (In reply to comment #1) > Неясно, зачем hal требует openmotif вообще. Он его не требует. Он требует лишь openmotif-demos: [c0der@mycomp ~]$ rpm -qR hal G motif 23:15 openmotif-demos 31839 3 ktirf 2005-10-13 20:21:50 +0400 Прошу прощения, погорячился. 31855 4 rider 2005-10-14 10:49:51 +0400 hal'у эти зависимости дейтсвительно не нужны. перевешиваю на пакет rpm-build, ибо openmotif почему-то вытягивается find-requires. 31869 5 ldv 2005-10-14 13:15:12 +0400 А при чём тут rpm-build? Нужна дополнительная информация. 31919 6 php-coder 2005-10-15 07:28:47 +0400 *** Bug 8222 has been marked as a duplicate of this bug. *** 32241 7 rider 2005-10-20 16:42:50 +0400 Вот дополнительная информация: $ for i in `fgrep openmotif /raid/ALT/branches/Sisyphus-branch-3.0/i586/base/contents_index |grep demos|grep bin|cut -f 1|sed -s "s,^.*\/,,"`;do fgrep $i *;done Бинарный файл hald совпадает hal-system-power-set-power-save: todo hal-system-power-set-power-save:todo() { hal-system-power-set-power-save: todo hal-system-power-set-power-save: todo hal-system-power-set-power-save: todo hal-system-power-set-power-save: todo hal-system-power-set-power-save: todo hal-system-power-set-power-save: todo Т.е. - в пакете openmotif-demos содержится программа с именем todo. А в скрипте /usr/bin/hal-system-power-set-power-save есть функция с именем todo и вызов этой функции в разных частях скрипта. findreq вытягивает почему-то todo не из скрипта, а из openmotif-demos 32244 8 rider 2005-10-20 16:56:58 +0400 тут inger предлагает некое решение: [16:48:17] <inger> я переименовал свою функцию [16:48:33] <Rider> ну я же не могу такой бредовый патч в mainstream послать [16:48:52] <inger> ну это конечно да, они имеют право на свои функции [16:49:10] <Rider> типа "мужики, у нас тут добанутый findreq, не называйте пожалуйста функции так, что бы они совпадали по имени с файлами из других пакетов" [16:49:11] <inger> надо бы наверное действительно попробовать мозг усилить у requires [16:49:32] <inger> ведь по идее shell умеет отличать процедуру от внешней проги (type) [16:49:37] <Rider> ну по идее да 32252 9 ldv 2005-10-20 17:03:40 +0400 Чтобы findreq "вытянул" функцию из скрипта, а не executable из индекса, нужно чтобы определение функции было доступно shell'у до первого использования. 32256 10 inger 2005-10-20 17:07:47 +0400 Дима, в любом случае это не правильно. findreq - должен давать ожидаемые результаты. А он не может сработать верно даже на скрипте из двух строчек. Мы же не будем править все скрипты на свете. 32258 11 inger 2005-10-20 17:08:14 +0400 Стоит засоурсить файл с функцией и крышу у req срывает. ---./zzz todo() { echo "aaa" } --- ---./l.sh . ./zzz todo --- Запускаем: $ ./l.sh aaa $bash --rpm-requires l.sh executable(/etc/bashrc) executable(todo) В случае когда функция в том же месте - всё работает отлично: ---- ./l.sh todo() { echo "aaa" } todo ----- $ bash --rpm-requires l.sh executable(/etc/bashrc) function(todo) 32260 12 ldv 2005-10-20 17:11:18 +0400 Я все свои скрипты давным-давно зафиксил. Так что проблемы в rpm-build не вижу. 32261 13 inger 2005-10-20 17:12:13 +0400 не стоит прогибаться под изменчивый мир, пусть лучше он прогнётся под нас. 32262 14 inger 2005-10-20 17:15:11 +0400 Это сложно исправить? Cкрипт даёт ложные разультаты на законных программах - не так ли? 32264 15 rider 2005-10-20 17:55:45 +0400 ну с моими скриптами тоже проблем нет. Есть явная проблема со скриптами "снаружи". Фиксить их все считаю бесмысленным увеличением затрат на сопровождение пакетов. Тем более что фикс будет заключаться в переименовывании функции. 32265 16 rider 2005-10-20 17:58:28 +0400 не стоит перевешивать багу обратно на hal. С точки зрения правил написания скриптв в hal ошибок нет. А вот неверный алгоритм поиска зависимостей в rpm-build - есть. Может быть стоит вообще отключить поиск зависимостей в шелловских скриптах ? Ибо вот такой пример: [ -x /bin/true ] && /bin/true Наверняка потянет за собой зависимость на на пакет с /bin/true. Хотя реально зависимость как бы и не нужна. 32266 17 rider 2005-10-20 17:58:56 +0400 Забыл reassign сделать обратно. 32267 18 rider 2005-10-20 18:00:53 +0400 Увеличиваю до blocker, ибо в текущей ситуации помимо всего прочего появление пакета, содержащего "левый" бинарный файл может привести к тому, что после пересборки репозитарий будет развален. 32268 19 rider 2005-10-20 18:03:00 +0400 Кстати, никому не кажется, что такой вот поиск зависимостей в шелловских скриптах выглядит немного бредово ? Примерно как искать вызовы dlopen и exec в бинарных файлах (вот только не надо этого делать). 32270 20 ldv 2005-10-20 18:45:17 +0400 Не надо пытаться тратить моё время впустую. 32287 21 rider 2005-10-21 10:09:17 +0400 Не стоит так поступать и с моим временем. 32297 22 ldv 2005-10-21 15:54:08 +0400 Антон, если тебе нужно, чтобы я реагировал на твои багрепорты, не надо перевешивать то, что я не считаю ошибкой в моём пакете, на мой пакет. Bugzilla, между прочим, имеет довольно удобные средства фильтрации. Если в твоём пакете find-requires находит зависимости, которые ты считаешь избыточными, то ничто тебе не мешает (на выбор): - отфильтровать ненужные зависимости - выключить поиск зависимостей этого типа - выключить поиск зависимостей вообще - заменить find-requires на другую программу - и т.п. Механизм поиска зависимостей в shell-скриптах в обозримом будущем я менять не планирую. 32302 23 rider 2005-10-21 16:09:24 +0400 Ну что ж, используй средства фильтрации. Я не считаю что это ошибка у меня в пакете. И еще раз просьба: не надо кушать мое (и других мантейнеров) время. IMHO проще исправить ошибку в одном пакете, а не в нескольких тысячах делать WORKAROUND'ы. Можешь закрывать как LATER, если сейчас не собираешься исправлять. Да, в hal-0.5.4-alt6 применен subst на эту функцию, изменяющий ее имя. 32303 24 ldv 2005-10-21 16:10:49 +0400 OK, договорились. 32308 25 raorn 2005-10-21 17:33:45 +0400 Однако, бага в hal, при чём действительно blocker. find-requires (а точнее bash) тут прав на все 100%: $ cat ~/bin/somefun #!/bin/sh echo hello from executable $ cat testfun #!/bin/sh somefun somefun () { echo hello from function } somefun $ ./testfun hello from executable hello from function $ 32309 26 raorn 2005-10-21 17:36:23 +0400 Ну и как следствие предыдущего камента: $ sh --rpm-requires ./testfun executable(somefun) function(somefun) А ведь именно так shell.req и работает... 32310 27 raorn 2005-10-21 17:36:57 +0400 Всё-таки hal.... 32311 28 raorn 2005-10-21 17:45:29 +0400 > Тем более что фикс будет заключаться в переименовывании функции. Фикс - перестановка определения функции todo до первого её использования. 32312 29 rider 2005-10-21 17:48:25 +0400 а эта фича sh --rpm-requires - она наша или есть во всех bash'ах ? 32313 30 rider 2005-10-21 17:50:16 +0400 Мда.. судя по bash-2.05b-rh-alt-requires.patch - наша. subst в качестве фикса меня устраивает больше.. не надо будет в mainstream патчи отправлять. Странные. 32315 31 legion 2005-10-21 19:59:49 +0400 sh --rpm-requires работает как предпроцессор он не выполняет команд(ни каких действий) ... только анализ кода. Исходя из этого если функция(алиас) объявлена в другом файле, который добавляется с помощью "source", то у shell нет возможности узнать что это ... функция или команда. 32335 32 php-coder 2005-10-23 13:02:15 +0400 Только сейчас заметил, что баг весит на hal и assign'ут на ldv@.. сейчас исправлю..:) 32336 33 php-coder 2005-10-23 13:06:36 +0400 .oO ( вот так подарочек на день рождения :)) блок-бага гг ) 32337 34 ldv 2005-10-23 14:46:13 +0400 Seems to be fixed in hal-0.5.4-alt6. 32348 35 php-coder 2005-10-23 21:14:12 +0400 Хех... а это что? и зачем оно мне? [c0der@mycomp ~]$ sudo apt-get install hal Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Следующие дополнительные пакеты будут установлены: acpid libhal Следующие пакеты будут ОБНОВЛЕНЫ: hal libhal Следующие НОВЫЕ пакеты будут установлены: acpid 2 будет обновлено, 1 новых установлено, 0 пакетов будет удалено и 32 не будет обновлено. Необходимо получить 368kB архивов. После распаковки потребуется дополнительно 39,9kB дискового пространства. Продолжить? [Y/n] n Прервано. <JT> Вот после такого люди и ставят софт из исходников и под Гентуу. Эти зависимости, причем ладно бы нужные, но ведь часто они не нужны.. кажется, помню возмущался, что kde захотел какой-то софт или библиотеку для беспроводных сетей, который у меня нет.. </JT> А в Дебиане, с его возможностью, указать рекомендуемые пакеты, но не обязательные все проще или нет? 32353 36 mike 2005-10-23 23:20:19 +0400 (In reply to comment #30) > subst в качестве фикса меня устраивает больше.. не надо будет в mainstream патчи > отправлять. Странные. Ну, можно обозвать это "cleanup", пояснив, что хорошие мальчики таки определяют функции до использования. :) 32381 37 rider 2005-10-24 15:35:55 +0400 (In reply to comment #35) > Хех... а это что? и зачем оно мне? > > [c0der@mycomp ~]$ sudo apt-get install hal > Чтение списков пакетов... Завершено > Построение дерева зависимостей... Завершено > Следующие дополнительные пакеты будут установлены: > acpid libhal > Следующие пакеты будут ОБНОВЛЕНЫ: > hal libhal > Следующие НОВЫЕ пакеты будут установлены: > acpid > 2 будет обновлено, 1 новых установлено, 0 пакетов будет удалено и 32 не будет > обновлено. > Необходимо получить 368kB архивов. > После распаковки потребуется дополнительно 39,9kB дискового пространства. > Продолжить? [Y/n] n > Прервано. > > <JT> > Вот после такого люди и ставят софт из исходников и под Гентуу. Эти зависимости, > причем ладно бы нужные, но ведь часто они не нужны.. кажется, помню возмущался, > что kde захотел какой-то софт или библиотеку для беспроводных сетей, который у > меня нет.. > </JT> > > А в Дебиане, с его возможностью, указать рекомендуемые пакеты, но не > обязательные все проще или нет? Новый hal теперь обязательно хочет acpid, ибо не умеет напрямую работать с /proc/acpi/events К сожалению, собрать hal именно таким образом - обязательная необходимость. Иначе на /proc/acpi/events будет идти в системе война, и этого нам не нужно. Но это уже не имеет отношения к этой ошибке