Bug 14244 - shell.req adds dependency on files inside conditionals
: shell.req adds dependency on files inside conditionals
Status: CLOSED WONTFIX
: Sisyphus
(All bugs in Sisyphus/rpm-build)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2008-01-30 11:32 by
Modified: 2011-08-12 11:40 (History)


Attachments


Note

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


Description From 2008-01-30 11:32:23
Наш мудрый поисковик зависимостей следующие конструкции:

if [ -d "/dev/elan" ] ; then
  FARCH="meiko"
elif [ -f /usr/bin/uxpm ] && /usr/bin/uxpm ; then
  FARCH="UXPM"
elif [ -f /usr/bin/uxpv ] && /usr/bin/uxpv ; then
  FARCH="uxpv"
fi

превращает в зависимости на /usr/bin/uxpm и на /usr/bin/uxpv, что совершенно не
правильно.
------- Comment #1 From 2008-01-30 14:19:42 -------
(In reply to comment #0)
> Наш мудрый поисковик зависимостей следующие конструкции:
> 
> if [ -d "/dev/elan" ] ; then
>   FARCH="meiko"
> elif [ -f /usr/bin/uxpm ] && /usr/bin/uxpm ; then
>   FARCH="UXPM"
> elif [ -f /usr/bin/uxpv ] && /usr/bin/uxpv ; then
>   FARCH="uxpv"
> fi
> 
> превращает в зависимости на /usr/bin/uxpm и на /usr/bin/uxpv, что совершенно не
> правильно.

Что же тут неправильного?  Он именно так он и должен работать.
------- Comment #2 From 2008-01-30 14:21:52 -------
Неправильного то, что и uxpm, и uxpv цепляются, а должно что-то одно.
------- Comment #3 From 2008-01-30 14:24:29 -------
(In reply to comment #2)
> Неправильного то, что и uxpm, и uxpv цепляются, а должно что-то одно.

Нет, в таком коде в зависимости должно попасть и то и другое.
------- Comment #4 From 2008-01-30 14:26:28 -------
Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут 
наматываться в огромном количестве?

PS: а где написано, "как должно быть"?
------- Comment #5 From 2008-01-30 23:59:17 -------
(In reply to comment #4)
> Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут 
> наматываться в огромном количестве?

Такого рода проверки встречаются в небольшом количестве.

> PS: а где написано, "как должно быть"?

Как должно быть где?
------- Comment #6 From 2008-01-31 00:00:30 -------
(In reply to comment #5)
> > PS: а где написано, "как должно быть"?
> Как должно быть где?

Как должно быть "вообще" - т.е. что есть The Right Thing для такой 
зависимостеискалки.
------- Comment #7 From 2008-01-31 00:04:35 -------
(In reply to comment #6)
> (In reply to comment #5)
> > > PS: а где написано, "как должно быть"?
> > Как должно быть где?
> 
> Как должно быть "вообще" - т.е. что есть The Right Thing для такой 
> зависимостеискалки.

The Right Thing для такой зависимостеискалки недостижим.
Всегда будут либо ложные срабатывания, либо пропуски, либо и то и другое.

Если и написано, то только как работает нынешняя.
------- Comment #8 From 2008-01-31 10:21:41 -------
нет, так быть не должно.

Если это сейчас исправить не возможно, то пусть остаётся на будущее.

Одно время в perl цеплялись зависимости типа (код пишу не не перле ;))

if (system == windows)
{
  require Win32
}

Это приводило к тому что в Сизиф цеплялись win32 модули. 

Если это считалось ошибкой, и было в своё время исправлено, то не понимаю почему
шелл такой особенный.

В приведённом коде нигде не было явной зависимости на использование утилит ибо
стояла проверка -f.

Повторюсь ещё раз: Если текущий поисковик зависмостей даёт _надмножество_
возможных зависимостей, а не _подмножество_, то это неправильно.
------- Comment #9 From 2008-01-31 13:03:52 -------
(In reply to comment #4)
> Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут 
> наматываться в огромном количестве?
Что особенно радует, когда код чужой и апстрим либо уже помер, либо не
собирается понижать читабельность кода за счёт решения наших собственных проблем.

> PS: а где написано, "как должно быть"?
В devel@ упоминалось:

x="/usr/sbin/x"
[ -x "$x" ] && "$x" ||:

Боюсь, на сейчас эта автоматизация будет приводить к возрастанию пакетов с
AutoReq: yes, noshell, как вот в spt.  За что боролись, на то пока и напарываемся :(

Может, получается сделать какой-то регулятор, в котором текущее поведение будет
равно "95%", а более раннее (год тому там) -- "80%"?  Для своих скриптов может
быть осмысленно стремиться к идеалу сильнее, чем для произвольных чужих.
------- Comment #10 From 2008-02-01 02:28:36 -------
Увы, сейчас поиск зависимостей в шелл-скриптах фактически диктует определённый
стиль написания этих скриптов (нужно "скрывать" более условные команды и,
наоборот, явно писать менее условные команды).  Жертва очень большая, да и
вообще автоматический поиск зависимостей в чисто интерпретируемых языках больше
похож на авантюру.  В менее интерпретируемых языках (где зависимости
осуществляются через систему модулей) нежалательные зависимости хотя бы легче
локализовать (и требуется поправить их более-менее "всего в одном месте"), а
тут
иногда получается, что весь код целиком нужно просматривать, имея в виду
автоматический поиск зависимостей.

Что тут можно сделать?  Это может быть целый research: нужно научить /bin/sh
дампить syntax tree в виде S-выражения и дальше match'ить это S-выражение по
шаблону типа case analysis.  Так что по идее можно отлавливать некоторые случаи
типа "проверка существования перед использованием".  Тут опять же есть два
варианта, либо чисто лексический анализ, либо дополнительно ещё контролируемое
частичное исполнение скрипта (c перехватом/запретом fork/exec/dup2).  Но
поскольку в шелле ничего нельзя сделать без форка и exec'а, то контролируемое
частичное исполнение скрипта опять оборачиватеся авантюрой.

Короче, мне в принципе интересно, есть ли в природе какие-нибудь research
papaers на эту тему (анализ условных зависимостей).

Кажется это по-научному называется Value Evolution Graph (VEG) --
http://www.google.com/search?q=%22Value+evolution+graph%22
------- Comment #11 From 2008-02-05 23:17:34 -------
*** Bug 14327 has been marked as a duplicate of this bug. ***
------- Comment #12 From 2008-02-25 23:10:53 -------
Я сомневаюсь в том, что этот вопрос будет решён в обозримом будущем.
------- Comment #13 From 2010-11-06 13:35:31 -------
Я тоже.