Bug 8211 - Неверная зависимость пакета hal
: Неверная зависимость пакета hal
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/hal)
: unstable
: all Linux
: P2 blocker
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-10-13 19:52 by
Modified: 2012-03-16 13:58 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-10-13 19:52:54
Лишняя, как мне кажется, зависимость на openmotif-demos. Этот пакет "contains
the Motif demo applications". Исходя из этого и просмотрев список файлов в
пакете я пришел к выводу, что hal'у оно не нужно.

Пожалуйста, удалите лишнюю зависимость..
------- Comment #1 From 2005-10-13 20:01:19 -------
Неясно, зачем hal требует openmotif вообще.
------- Comment #2 From 2005-10-13 20:18:27 -------
(In reply to comment #1)
> Неясно, зачем hal требует openmotif вообще.

Он его не требует. Он требует лишь openmotif-demos:

[c0der@mycomp ~]$ rpm -qR hal G motif                                     23:15
openmotif-demos
------- Comment #3 From 2005-10-13 20:21:50 -------
Прошу прощения, погорячился.
------- Comment #4 From 2005-10-14 10:49:51 -------
hal'у эти зависимости дейтсвительно не нужны.
перевешиваю на пакет rpm-build, ибо openmotif почему-то вытягивается find-requires.
------- Comment #5 From 2005-10-14 13:15:12 -------
А при чём тут rpm-build?  Нужна дополнительная информация.
------- Comment #6 From 2005-10-15 07:28:47 -------
*** Bug 8222 has been marked as a duplicate of this bug. ***
------- Comment #7 From 2005-10-20 16:42:50 -------
Вот дополнительная информация:
$ 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
------- Comment #8 From 2005-10-20 16:56:58 -------
тут 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> ну по идее да
------- Comment #9 From 2005-10-20 17:03:40 -------
Чтобы findreq "вытянул" функцию из скрипта, а не executable из индекса, нужно
чтобы определение функции было доступно shell'у до первого использования.
------- Comment #10 From 2005-10-20 17:07:47 -------
Дима, в любом случае это не правильно.

findreq - должен давать ожидаемые результаты. А он не может сработать верно даже
на скрипте из двух строчек.

Мы же не будем править все скрипты на свете.
------- Comment #11 From 2005-10-20 17:08:14 -------
Стоит засоурсить файл с функцией и крышу у 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)
------- Comment #12 From 2005-10-20 17:11:18 -------
Я все свои скрипты давным-давно зафиксил.
Так что проблемы в rpm-build не вижу.
------- Comment #13 From 2005-10-20 17:12:13 -------
не стоит прогибаться под изменчивый мир, пусть лучше он прогнётся под нас.
------- Comment #14 From 2005-10-20 17:15:11 -------
Это сложно исправить? Cкрипт даёт ложные разультаты на законных программах - не
так ли?
------- Comment #15 From 2005-10-20 17:55:45 -------
ну с моими скриптами тоже проблем нет. Есть явная проблема со скриптами
"снаружи".

Фиксить их все считаю бесмысленным увеличением затрат на сопровождение пакетов.

Тем более что фикс будет заключаться в переименовывании функции.
------- Comment #16 From 2005-10-20 17:58:28 -------
не стоит перевешивать багу обратно на hal. С точки зрения правил написания
скриптв в hal ошибок нет.

А вот неверный алгоритм поиска зависимостей в rpm-build - есть. 

Может быть стоит вообще отключить поиск зависимостей в шелловских скриптах ?

Ибо вот такой пример:
[ -x /bin/true ] && /bin/true

Наверняка потянет за собой зависимость на на пакет с /bin/true. Хотя реально
зависимость как бы и не нужна.
------- Comment #17 From 2005-10-20 17:58:56 -------
Забыл reassign сделать обратно.
------- Comment #18 From 2005-10-20 18:00:53 -------
Увеличиваю до blocker, ибо в текущей ситуации помимо всего прочего появление
пакета, содержащего "левый" бинарный файл может привести к тому, что после
пересборки репозитарий будет развален.
------- Comment #19 From 2005-10-20 18:03:00 -------
Кстати, никому не кажется, что такой вот поиск зависимостей в шелловских
скриптах выглядит немного бредово ?

Примерно как искать вызовы dlopen и exec в бинарных файлах (вот только не надо
этого делать).
------- Comment #20 From 2005-10-20 18:45:17 -------
Не надо пытаться тратить моё время впустую.
------- Comment #21 From 2005-10-21 10:09:17 -------
Не стоит так поступать и с моим временем.
------- Comment #22 From 2005-10-21 15:54:08 -------
Антон, если тебе нужно, чтобы я реагировал на твои багрепорты,
не надо перевешивать то, что я не считаю ошибкой в моём пакете, на мой пакет.
Bugzilla, между прочим, имеет довольно удобные средства фильтрации.

Если в твоём пакете find-requires находит зависимости, которые ты считаешь
избыточными, то ничто тебе не мешает (на выбор):
- отфильтровать ненужные зависимости
- выключить поиск зависимостей этого типа
- выключить поиск зависимостей вообще
- заменить find-requires на другую программу
- и т.п.

Механизм поиска зависимостей в shell-скриптах в обозримом будущем я менять не
планирую.
------- Comment #23 From 2005-10-21 16:09:24 -------
Ну что ж, используй средства фильтрации. Я не считаю что это ошибка у меня в
пакете. И еще раз просьба: не надо кушать мое  (и других мантейнеров) время.

IMHO проще исправить ошибку в одном пакете, а не в нескольких тысячах делать
WORKAROUND'ы.

Можешь закрывать как LATER, если сейчас не собираешься исправлять.

Да, в hal-0.5.4-alt6 применен subst на эту функцию, изменяющий ее имя.
------- Comment #24 From 2005-10-21 16:10:49 -------
OK, договорились.
------- Comment #25 From 2005-10-21 17:33:45 -------
Однако, бага в 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
$
------- Comment #26 From 2005-10-21 17:36:23 -------
Ну и как следствие предыдущего камента:

$ sh --rpm-requires ./testfun
executable(somefun)
function(somefun)

А ведь именно так shell.req и работает...
------- Comment #27 From 2005-10-21 17:36:57 -------
Всё-таки hal....
------- Comment #28 From 2005-10-21 17:45:29 -------
> Тем более что фикс будет заключаться в переименовывании функции.

Фикс - перестановка определения функции todo до первого её использования.
------- Comment #29 From 2005-10-21 17:48:25 -------
а эта фича sh --rpm-requires - она наша или есть во всех bash'ах ?
------- Comment #30 From 2005-10-21 17:50:16 -------
Мда.. судя по bash-2.05b-rh-alt-requires.patch - наша.

subst в качестве фикса меня устраивает больше.. не надо будет в mainstream патчи
отправлять. Странные.
------- Comment #31 From 2005-10-21 19:59:49 -------
sh --rpm-requires работает как предпроцессор он не выполняет команд(ни каких
действий) ... только анализ кода. Исходя из этого если функция(алиас) объявлена
в другом файле, который добавляется с помощью "source", то у shell нет
возможности узнать что это ... функция или команда.
------- Comment #32 From 2005-10-23 13:02:15 -------
Только сейчас заметил, что баг весит на hal и assign'ут на ldv@.. сейчас
исправлю..:)
------- Comment #33 From 2005-10-23 13:06:36 -------
.oO ( вот так подарочек на день рождения :)) блок-бага гг )
------- Comment #34 From 2005-10-23 14:46:13 -------
Seems to be fixed in hal-0.5.4-alt6.
------- Comment #35 From 2005-10-23 21:14:12 -------
Хех... а это что? и зачем оно мне?

[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>

А в Дебиане, с его возможностью, указать рекомендуемые пакеты, но не
обязательные все проще или нет?
------- Comment #36 From 2005-10-23 23:20:19 -------
(In reply to comment #30)
> subst в качестве фикса меня устраивает больше.. не надо будет в mainstream патчи
> отправлять. Странные.
Ну, можно обозвать это "cleanup", пояснив, что хорошие мальчики таки определяют
функции до использования. :)
------- Comment #37 From 2005-10-24 15:35:55 -------
(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 будет идти в системе война, и этого нам не нужно.

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