14244 2008-01-30 11:32:23 +0300 shell.req adds dependency on files inside conditionals 2011-08-12 11:40:12 +0400 1 1 4 Development Sisyphus rpm-build unstable all Linux CLOSED WONTFIX P2 normal --- 1 inger nobody arseny dd1email evg glebfm imz lakostis ldv legion mike placeholder radik viy vt vvk qa-sisyphus oldest_to_newest 62288 0 inger 2008-01-30 11:32:23 +0300 Наш мудрый поисковик зависимостей следующие конструкции: 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, что совершенно не правильно. 62299 1 ldv 2008-01-30 14:19:42 +0300 (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, что совершенно не > правильно. Что же тут неправильного? Он именно так он и должен работать. 62301 2 dottedmag 2008-01-30 14:21:52 +0300 Неправильного то, что и uxpm, и uxpv цепляются, а должно что-то одно. 62302 3 ldv 2008-01-30 14:24:29 +0300 (In reply to comment #2) > Неправильного то, что и uxpm, и uxpv цепляются, а должно что-то одно. Нет, в таком коде в зависимости должно попасть и то и другое. 62303 4 dottedmag 2008-01-30 14:26:28 +0300 Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут наматываться в огромном количестве? PS: а где написано, "как должно быть"? 62321 5 ldv 2008-01-30 23:59:17 +0300 (In reply to comment #4) > Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут > наматываться в огромном количестве? Такого рода проверки встречаются в небольшом количестве. > PS: а где написано, "как должно быть"? Как должно быть где? 62322 6 dottedmag 2008-01-31 00:00:30 +0300 (In reply to comment #5) > > PS: а где написано, "как должно быть"? > Как должно быть где? Как должно быть "вообще" - т.е. что есть The Right Thing для такой зависимостеискалки. 62324 7 ldv 2008-01-31 00:04:35 +0300 (In reply to comment #6) > (In reply to comment #5) > > > PS: а где написано, "как должно быть"? > > Как должно быть где? > > Как должно быть "вообще" - т.е. что есть The Right Thing для такой > зависимостеискалки. The Right Thing для такой зависимостеискалки недостижим. Всегда будут либо ложные срабатывания, либо пропуски, либо и то и другое. Если и написано, то только как работает нынешняя. 62345 8 inger 2008-01-31 10:21:41 +0300 нет, так быть не должно. Если это сейчас исправить не возможно, то пусть остаётся на будущее. Одно время в perl цеплялись зависимости типа (код пишу не не перле ;)) if (system == windows) { require Win32 } Это приводило к тому что в Сизиф цеплялись win32 модули. Если это считалось ошибкой, и было в своё время исправлено, то не понимаю почему шелл такой особенный. В приведённом коде нигде не было явной зависимости на использование утилит ибо стояла проверка -f. Повторюсь ещё раз: Если текущий поисковик зависмостей даёт _надмножество_ возможных зависимостей, а не _подмножество_, то это неправильно. 62352 9 mike 2008-01-31 13:03:52 +0300 (In reply to comment #4) > Т.е. в любом нетривиальном коде такого рода "левые" зависимости будут > наматываться в огромном количестве? Что особенно радует, когда код чужой и апстрим либо уже помер, либо не собирается понижать читабельность кода за счёт решения наших собственных проблем. > PS: а где написано, "как должно быть"? В devel@ упоминалось: x="/usr/sbin/x" [ -x "$x" ] && "$x" ||: Боюсь, на сейчас эта автоматизация будет приводить к возрастанию пакетов с AutoReq: yes, noshell, как вот в spt. За что боролись, на то пока и напарываемся :( Может, получается сделать какой-то регулятор, в котором текущее поведение будет равно "95%", а более раннее (год тому там) -- "80%"? Для своих скриптов может быть осмысленно стремиться к идеалу сильнее, чем для произвольных чужих. 62411 10 at 2008-02-01 02:28:36 +0300 Увы, сейчас поиск зависимостей в шелл-скриптах фактически диктует определённый стиль написания этих скриптов (нужно "скрывать" более условные команды и, наоборот, явно писать менее условные команды). Жертва очень большая, да и вообще автоматический поиск зависимостей в чисто интерпретируемых языках больше похож на авантюру. В менее интерпретируемых языках (где зависимости осуществляются через систему модулей) нежалательные зависимости хотя бы легче локализовать (и требуется поправить их более-менее "всего в одном месте"), а тут иногда получается, что весь код целиком нужно просматривать, имея в виду автоматический поиск зависимостей. Что тут можно сделать? Это может быть целый 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 62707 11 ldv 2008-02-05 23:17:34 +0300 *** Bug 14327 has been marked as a duplicate of this bug. *** 64600 12 ldv 2008-02-25 23:10:53 +0300 Я сомневаюсь в том, что этот вопрос будет решён в обозримом будущем. 114916 13 mike 2010-11-06 13:35:31 +0300 Я тоже.