Bug 14244 - shell.req adds dependency on files inside conditionals
Summary: shell.req adds dependency on files inside conditionals
Status: CLOSED WONTFIX
Alias: None
Product: Sisyphus
Classification: Development
Component: rpm-build (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: Nobody's working on this, feel free to take it
QA Contact: qa-sisyphus
URL:
Keywords:
: 14327 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-01-30 11:32 MSK by inger@altlinux.org
Modified: 2011-08-12 11:40 MSK (History)
14 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description inger@altlinux.org 2008-01-30 11:32:23 MSK
Наш мудрый поисковик зависимостей следующие конструкции:

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 Dmitry V. Levin 2008-01-30 14:19:42 MSK
(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 Mikhail Gusarov 2008-01-30 14:21:52 MSK
Неправильного то, что и uxpm, и uxpv цепляются, а должно что-то одно.
Comment 3 Dmitry V. Levin 2008-01-30 14:24:29 MSK
(In reply to comment #2)
> Неправильного то, что и uxpm, и uxpv цепляются, а должно что-то одно.

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

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

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

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

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

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

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

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

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

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

if (system == windows)
{
  require Win32
}

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

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

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

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

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

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

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

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

Что тут можно сделать?  Это может быть целый 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 Dmitry V. Levin 2008-02-05 23:17:34 MSK
*** Bug 14327 has been marked as a duplicate of this bug. ***
Comment 12 Dmitry V. Levin 2008-02-25 23:10:53 MSK
Я сомневаюсь в том, что этот вопрос будет решён в обозримом будущем.
Comment 13 Michael Shigorin 2010-11-06 13:35:31 MSK
Я тоже.