21796 2009-09-30 20:51:52 +0400 %post -p /etc/cron.daily/makewhatis 2009-10-16 19:17:58 +0400 1 1 4 Development Sisyphus man-pages unstable all Linux CLOSED FIXED P3 blocker --- 1 shrek placeholder asy evg george glebfm ldv led legion mike placeholder solo vt wrar qa-sisyphus oldest_to_newest 100528 0 shrek 2009-09-30 20:51:52 +0400 с каких это пор у нас принято вызывать кроновские скрипты из post? у меня давно сделано # rm -f /etc/cron.*/makewhatis ибо эта ежедневная ересь мне не нужна, в результате каждая установка man-pages обламывается 100553 1 php-coder 2009-10-01 09:38:55 +0400 А что предлагается взамен? Просто вызывать /usr/sbin/makewhatis -u? 100620 2 solo 2009-10-01 22:10:20 +0400 (В ответ на комментарий №1) > А что предлагается взамен? Просто вызывать /usr/sbin/makewhatis -u? Думаю более правельный вариант. 100626 3 asy 2009-10-02 00:08:52 +0400 А если класть в cron.hourly скрипт с названием, скажем, makewhatis_once, который завершается командой "rm -f $0" ? 100784 4 mike 2009-10-05 03:19:30 +0400 Также замечено, что скрипт вполне может завершаться с ненулевым кодом возврата и уже потому если его и запускать из %post, то исключительно с заглушкой (||:). 100830 5 asy 2009-10-05 19:41:27 +0400 (In reply to comment #4) Так это blocker тогда... Кстати, ещё, как вариант: /usr/sbin/makewhatis -u & В общем я к тому, что не нужна такая пауза при установке пакета. 100831 6 led 2009-10-05 19:47:33 +0400 (В ответ на комментарий №5) > (In reply to comment #4) > > Так это blocker тогда... Кстати, ещё, как вариант: > /usr/sbin/makewhatis -u & Тогда уж "как вариант" - запуск mklocatedb после установки/удаления каждого пакета. Зачем это нужно? 100833 7 php-coder 2009-10-05 19:57:40 +0400 (В ответ на комментарий №5) > (In reply to comment #4) > > Так это blocker тогда... Согласно http://www.altlinux.org/BugSeverityPolicy, ошибка с серьёзностью blocker "ломает не связанное с данным ПО (или даже всю систему), вызывает серьёзные потери данных, создаёт дыру в безопасности при установке пакета". В долгом выполнении постустановочного скрипта нет ничего опасного и он не ломает другое ПО. По этой причине я считаю, что это не blocker, а скорее minor (возможно, normal). 100834 8 shrek 2009-10-05 20:04:31 +0400 apt-get после такого облома работать перестает. достаточно для "ломает всю систему"? 100836 9 asy 2009-10-05 20:07:32 +0400 (In reply to comment #7) > По этой причине я считаю, что это не blocker, а скорее minor про "долго" - это попутный ворос. Главное - это то, что Шигорин в #4 написал. 100837 10 asy 2009-10-05 20:10:28 +0400 (In reply to comment #6) > Тогда уж "как вариант" - запуск mklocatedb после установки/удаления каждого > пакета. Зачем это нужно? Я не занимался анализом ситуации на тему "зачем". Это пусть мантейнер думает. А вот вопрс "как" мне интересен. 100843 11 php-coder 2009-10-05 20:15:49 +0400 (В ответ на комментарий №8) > apt-get после такого облома работать перестает. достаточно для "ломает всю > систему"? К сожалению, нет, так как система в которой удален файл /etc/cron.daily/makewhatis не является типичной. Если так мешает этот скрипт, то можно его сделать пустым ;) Тогда и апгрейд будет работать и makewhatis не будет долго выполняться. 100844 12 shrek 2009-10-05 20:19:06 +0400 к сожалению да, т.к. для /etc/cron.daily/makewhatis совершенно нормально выход с 1, что дает тот же результат что и его отсутствие 100846 13 php-coder 2009-10-05 20:25:50 +0400 (В ответ на комментарий №12) > к сожалению да, т.к. для /etc/cron.daily/makewhatis совершенно нормально выход > с 1, что дает тот же результат что и его отсутствие Согласно коду с 1 он выходит, только если уже запущен и его пытаются запускать вновь. На моей машине этого ни разу не было, возможно, что на системах с несколькими процессорами это имеет место быть. Валер, я могу добавить ||: в %post, это тебя устроит? Выносить вызов makewhatis из скрипта не хочется, по той причине, что там есть дополнительная логика (например, скрипт не запускается при установке системы и при установке в хашере) и её придётся тогда тоже за собой тащить, а по пути есть шанс что-нибудь сломать :( Если основные претензии к тому что makewhatis долго выполняется, то это уже пожелание к пакету man, чтобы ускорить выполнение этого скрипта. 100847 14 mike 2009-10-05 20:29:28 +0400 (In reply to comment #13) > Валер, я могу добавить ||: в %post, это тебя устроит? Меня вот -- да. > Выносить вызов makewhatis из скрипта не хочется, по той причине, что там есть > дополнительная логика (например, скрипт не запускается при установке системы и > при установке в хашере) и её придётся тогда тоже за собой тащить, а по пути > есть шанс что-нибудь сломать :( Ввиду bug #21838 предлагаю завернуть в проверку с опосредованием имени скрипта через переменную, чтоб не ругалось при отсутствии makewhatis и не тащило содержащий его пакет. 100849 15 php-coder 2009-10-05 20:32:17 +0400 (В ответ на комментарий №14) > Ввиду bug #21838 предлагаю завернуть в проверку с опосредованием имени скрипта > через переменную, чтоб не ругалось при отсутствии makewhatis и не тащило > содержащий его пакет. Вроде такого? MAKEWHATIS=/etc/cron.daily/makewhatis if [ -x "$MAKEWHATIS" ]; then $MAKEWHATIS || : fi 100850 16 mike 2009-10-05 20:35:44 +0400 (In reply to comment #15) > Вроде такого? Почти -- эта конструкция может вернуть non-zero при невыполнении теста, и если будет последней в %post -- то rpm сочтёт процесс завершившимся с ошибкой. Обычно либо инвертируют тест/действие ([ ! -x ] || ...), ну или можно и if заткнуть: MAKEWHATIS=/etc/cron.daily/makewhatis if [ -x "$MAKEWHATIS" ]; then $MAKEWHATIS || : fi || : 100853 17 asy 2009-10-05 20:39:04 +0400 А, всё-таки, почему бы & не использовать ? Результат-то не важен, пусть в фоне шуршит и не тормозит процесс установки. 100854 18 shrek 2009-10-05 20:39:49 +0400 %post [ -n "$DURING_INSTALL" ] || su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis -u' ||: это простой вариан, можно еще добавить lock файл 100855 19 led 2009-10-05 20:41:10 +0400 Нужно отделить мух от котлет и признать, что скрипт для cron и post-script - это разные вещи, и не пытать на^Wобмануть судьбу и не "скрещивать ежа с ужом" 100856 20 php-coder 2009-10-05 20:44:10 +0400 (В ответ на комментарий №18) > %post > [ -n "$DURING_INSTALL" ] || su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis > -u' ||: > > это простой вариан, можно еще добавить lock файл Надо ещё учесть переменную $FAKEROOTKEY (см. bug #11488) 100857 21 shrek 2009-10-05 20:50:41 +0400 [ -n "$DURING_INSTALL" -o -n "$FAKEROOTKEY" ] || 100858 22 shrek 2009-10-05 21:07:12 +0400 %post if [ -z "$DURING_INSTALL" -o -z "$FAKEROOTKEY" ]; then su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis -u' ||: fi вот тебе практически окончательный вариант 100864 23 legion 2009-10-05 22:47:06 +0400 Я очень прошу: не вызывайте makewhatis из %post вообще. Это в корне не правильное решение... не важно с какой обвязкой вокруг этой утилиты это делается. База whatis строится/обновляется из другого места. Если так хочется иметь обновлённую базу whatis прямо немедленно после установки rpm пакета, содержащего man-страницы, то лучше придумать триггер для rpm. Но в _любом_ случае обновление базы это не забота пакета с man-страницами. 100872 24 mike 2009-10-06 01:46:28 +0400 (In reply to comment #23) > Если так хочется иметь обновлённую базу whatis прямо немедленно после установки > rpm пакета, содержащего man-страницы, то лучше придумать триггер для rpm. Это тоже да, но вроде уже прозвучало же? (насколько понимаю, предложенный кусочек кода лучше как раз закинуть в posttrans filetrigger в пакете man) 100874 25 legion 2009-10-06 01:53:25 +0400 (В ответ на комментарий №24) > Это тоже да, но вроде уже прозвучало же? (насколько понимаю, предложенный > кусочек кода лучше как раз закинуть в posttrans filetrigger в пакете man) Возможно проглядел, если прозвучало, то отлично. В любом случае, в контексте этой баги, НЕ нужно вызывать makewhatis вообще никаким образом из этого пакета а равно и из других пакетов с манами. 100878 26 php-coder 2009-10-06 09:29:39 +0400 (В ответ на комментарий №23) > Я очень прошу: не вызывайте makewhatis из %post вообще. Это можно будет сделать когда в rpm появится соответствующий триггер. Вопрос в том когда он появится? 100895 27 legion 2009-10-06 13:53:50 +0400 (В ответ на комментарий №26) > Это можно будет сделать когда в rpm появится соответствующий триггер. Вопрос в > том когда он появится? Это нужно сделать безотносительно того, когда появится триггер. 100896 28 php-coder 2009-10-06 13:57:55 +0400 (В ответ на комментарий №27) > Это нужно сделать безотносительно того, когда появится триггер. У нас вызов makewhatis уже несколько лет как во всех man-pages используется и я не вижу причины почему не стОит подождать ещё неделю-другую/месяц-два до появления триггеров. 100902 29 legion 2009-10-06 14:32:17 +0400 (В ответ на комментарий №28) > У нас вызов makewhatis уже несколько лет как во всех man-pages используется и я > не вижу причины почему не стОит подождать ещё неделю-другую/месяц-два до > появления триггеров. Несколько лет во всех man-pages занимались не своим делом. Я не вижу причин этим пакетам продолжать это делать. Как подтверждение - сама эта бага. 100905 30 asy 2009-10-06 15:03:44 +0400 А можно, пока, добавить ||: ? Снимем blocker и продолжайте спокойно спорить. :-) 100906 31 shrek 2009-10-06 15:12:33 +0400 не можно, ибо не нужно 101252 32 php-coder 2009-10-11 19:28:59 +0400 Господа, завышение важности бага, в данном случае, не ускорит решение проблемы. 101254 33 shrek 2009-10-11 19:33:08 +0400 да нет, оно blocker, т.к. легко загоняет apt в нерабочее состояние 101256 34 php-coder 2009-10-11 19:48:41 +0400 (В ответ на комментарий №22) > %post > if [ -z "$DURING_INSTALL" -o -z "$FAKEROOTKEY" ]; then > su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis -u' ||: > fi > > вот тебе практически окончательный вариант Только здесь не -o a -a, т.к. обе переменные должны быть пустыми. Сделаю в следующей сборке, чтобы наконец уже закрыть этот баг. Когда появятся триггеры -- уберу совсем. 101259 35 shrek 2009-10-11 19:59:45 +0400 (В ответ на комментарий №34) > (В ответ на комментарий №22) > > %post > > if [ -z "$DURING_INSTALL" -o -z "$FAKEROOTKEY" ]; then > > su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis -u' ||: > > fi > > > > вот тебе практически окончательный вариант > > Только здесь не -o a -a, т.к. обе переменные должны быть пустыми. да нет, там -o, а не -a > Сделаю в следующей сборке, чтобы наконец уже закрыть этот баг. сколько раз нужно еще повторить что вызывать makewhatis вообще не нужно что бы Вы это поняли? > Когда появятся триггеры -- уберу совсем. их кто то обещал? 101260 36 php-coder 2009-10-11 20:08:41 +0400 (В ответ на комментарий №35) > (В ответ на комментарий №34) > > (В ответ на комментарий №22) > > > %post > > > if [ -z "$DURING_INSTALL" -o -z "$FAKEROOTKEY" ]; then > > > su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis -u' ||: > > > fi > > > > > > вот тебе практически окончательный вариант > > > > Только здесь не -o a -a, т.к. обе переменные должны быть пустыми. > > да нет, там -o, а не -a Поясни, пожалуйста, почему? > сколько раз нужно еще повторить что вызывать makewhatis вообще не нужно что бы > Вы это поняли? Мне не нужно повторять, я это понял. Но пока нет триггеров, если убрать ручной вызов makewhatis, то маны перестанут индексироваться и apropos/whatis перестанут работать. Поэтому до появления триггеров, я не буду убирать вызов makewhatis. Сейчас я могу заменить вызов кроновского скрипта на код, приведённый выше, который ты предложил. Тебя это устроит? > > Когда появятся триггеры -- уберу совсем. > > их кто то обещал? Нет. Пока нет. Скоро я повешу баг и будем уже решать с legion@-ом эту проблему. (Но это будет уже другая проблема и другой баг.) 101261 37 shrek 2009-10-11 20:21:17 +0400 (В ответ на комментарий №36) > > да нет, там -o, а не -a > > Поясни, пожалуйста, почему? DURING_INSTALL и FAKEROOTKEY решают разные задачи и используются в совершенно разных местах > > сколько раз нужно еще повторить что вызывать makewhatis вообще не нужно что бы > > Вы это поняли? > > Мне не нужно повторять, я это понял. Но пока нет триггеров, если убрать ручной > вызов makewhatis, то маны перестанут индексироваться и apropos/whatis > перестанут работать. см. https://bugzilla.altlinux.org/show_bug.cgi?id=21793 > Поэтому до появления триггеров, я не буду убирать вызов > makewhatis. Сейчас я могу заменить вызов кроновского скрипта на код, > приведённый выше, который ты предложил. Тебя это устроит? возможно это устроит apt > > > Когда появятся триггеры -- уберу совсем. man-pages-ru я давно вынес, видимо придется избавиться и от этого 101371 38 mike 2009-10-12 23:43:01 +0400 (In reply to comment #36) > Мне не нужно повторять, я это понял. Но пока нет триггеров, если убрать ручной > вызов makewhatis, то маны перестанут индексироваться и apropos/whatis > перестанут работать. Ну почему -- cron-скрипт пока есть, когда-то да отработает. > Поэтому до появления триггеров, я не буду убирать вызов makewhatis. Убери, пожалуйста -- это исправит больше, чем сломает. Сейчас есть риск сломать apt (я тоже напоролся), а пользователи apropos должны быть достаточно сообразительны, чтоб при крайней нужде и руками его запустить (или перекронить, или сделать наконец этот файлтриггер). 2 shrek: тебе действительно охота быть местным Al Viro? 101689 39 repository-robot 2009-10-16 19:12:03 +0400 man-pages-3.23-alt2 -> sisyphus: * Fri Oct 16 2009 Slava Semushin <php-coder@altlinux> 3.23-alt2 - Don't call makewhatis after installation (Closes: #21796) - Added explicit Conflicts with libcint-devel (noted by repocop)