Лишняя, как мне кажется, зависимость на openmotif-demos. Этот пакет "contains the Motif demo applications". Исходя из этого и просмотрев список файлов в пакете я пришел к выводу, что hal'у оно не нужно. Пожалуйста, удалите лишнюю зависимость..
Неясно, зачем hal требует openmotif вообще.
(In reply to comment #1) > Неясно, зачем hal требует openmotif вообще. Он его не требует. Он требует лишь openmotif-demos: [c0der@mycomp ~]$ rpm -qR hal G motif 23:15 openmotif-demos
Прошу прощения, погорячился.
hal'у эти зависимости дейтсвительно не нужны. перевешиваю на пакет rpm-build, ибо openmotif почему-то вытягивается find-requires.
А при чём тут rpm-build? Нужна дополнительная информация.
*** Bug 8222 has been marked as a duplicate of this bug. ***
Вот дополнительная информация: $ 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
тут 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> ну по идее да
Чтобы findreq "вытянул" функцию из скрипта, а не executable из индекса, нужно чтобы определение функции было доступно shell'у до первого использования.
Дима, в любом случае это не правильно. findreq - должен давать ожидаемые результаты. А он не может сработать верно даже на скрипте из двух строчек. Мы же не будем править все скрипты на свете.
Стоит засоурсить файл с функцией и крышу у 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)
Я все свои скрипты давным-давно зафиксил. Так что проблемы в rpm-build не вижу.
не стоит прогибаться под изменчивый мир, пусть лучше он прогнётся под нас.
Это сложно исправить? Cкрипт даёт ложные разультаты на законных программах - не так ли?
ну с моими скриптами тоже проблем нет. Есть явная проблема со скриптами "снаружи". Фиксить их все считаю бесмысленным увеличением затрат на сопровождение пакетов. Тем более что фикс будет заключаться в переименовывании функции.
не стоит перевешивать багу обратно на hal. С точки зрения правил написания скриптв в hal ошибок нет. А вот неверный алгоритм поиска зависимостей в rpm-build - есть. Может быть стоит вообще отключить поиск зависимостей в шелловских скриптах ? Ибо вот такой пример: [ -x /bin/true ] && /bin/true Наверняка потянет за собой зависимость на на пакет с /bin/true. Хотя реально зависимость как бы и не нужна.
Забыл reassign сделать обратно.
Увеличиваю до blocker, ибо в текущей ситуации помимо всего прочего появление пакета, содержащего "левый" бинарный файл может привести к тому, что после пересборки репозитарий будет развален.
Кстати, никому не кажется, что такой вот поиск зависимостей в шелловских скриптах выглядит немного бредово ? Примерно как искать вызовы dlopen и exec в бинарных файлах (вот только не надо этого делать).
Не надо пытаться тратить моё время впустую.
Не стоит так поступать и с моим временем.
Антон, если тебе нужно, чтобы я реагировал на твои багрепорты, не надо перевешивать то, что я не считаю ошибкой в моём пакете, на мой пакет. Bugzilla, между прочим, имеет довольно удобные средства фильтрации. Если в твоём пакете find-requires находит зависимости, которые ты считаешь избыточными, то ничто тебе не мешает (на выбор): - отфильтровать ненужные зависимости - выключить поиск зависимостей этого типа - выключить поиск зависимостей вообще - заменить find-requires на другую программу - и т.п. Механизм поиска зависимостей в shell-скриптах в обозримом будущем я менять не планирую.
Ну что ж, используй средства фильтрации. Я не считаю что это ошибка у меня в пакете. И еще раз просьба: не надо кушать мое (и других мантейнеров) время. IMHO проще исправить ошибку в одном пакете, а не в нескольких тысячах делать WORKAROUND'ы. Можешь закрывать как LATER, если сейчас не собираешься исправлять. Да, в hal-0.5.4-alt6 применен subst на эту функцию, изменяющий ее имя.
OK, договорились.
Однако, бага в 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 $
Ну и как следствие предыдущего камента: $ sh --rpm-requires ./testfun executable(somefun) function(somefun) А ведь именно так shell.req и работает...
Всё-таки hal....
> Тем более что фикс будет заключаться в переименовывании функции. Фикс - перестановка определения функции todo до первого её использования.
а эта фича sh --rpm-requires - она наша или есть во всех bash'ах ?
Мда.. судя по bash-2.05b-rh-alt-requires.patch - наша. subst в качестве фикса меня устраивает больше.. не надо будет в mainstream патчи отправлять. Странные.
sh --rpm-requires работает как предпроцессор он не выполняет команд(ни каких действий) ... только анализ кода. Исходя из этого если функция(алиас) объявлена в другом файле, который добавляется с помощью "source", то у shell нет возможности узнать что это ... функция или команда.
Только сейчас заметил, что баг весит на hal и assign'ут на ldv@.. сейчас исправлю..:)
.oO ( вот так подарочек на день рождения :)) блок-бага гг )
Seems to be fixed in hal-0.5.4-alt6.
Хех... а это что? и зачем оно мне? [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> А в Дебиане, с его возможностью, указать рекомендуемые пакеты, но не обязательные все проще или нет?
(In reply to comment #30) > subst в качестве фикса меня устраивает больше.. не надо будет в mainstream патчи > отправлять. Странные. Ну, можно обозвать это "cleanup", пояснив, что хорошие мальчики таки определяют функции до использования. :)
(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 будет идти в системе война, и этого нам не нужно. Но это уже не имеет отношения к этой ошибке
