Неясно, зачем 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 будет идти в системе война, и этого нам не нужно.

Но это уже не имеет отношения к этой ошибке