с каких это пор у нас принято вызывать кроновские скрипты из post? у меня давно сделано # rm -f /etc/cron.*/makewhatis ибо эта ежедневная ересь мне не нужна, в результате каждая установка man-pages обламывается
А что предлагается взамен? Просто вызывать /usr/sbin/makewhatis -u?
(В ответ на комментарий №1) > А что предлагается взамен? Просто вызывать /usr/sbin/makewhatis -u? Думаю более правельный вариант.
А если класть в cron.hourly скрипт с названием, скажем, makewhatis_once, который завершается командой "rm -f $0" ?
Также замечено, что скрипт вполне может завершаться с ненулевым кодом возврата и уже потому если его и запускать из %post, то исключительно с заглушкой (||:).
(In reply to comment #4) Так это blocker тогда... Кстати, ещё, как вариант: /usr/sbin/makewhatis -u & В общем я к тому, что не нужна такая пауза при установке пакета.
(В ответ на комментарий №5) > (In reply to comment #4) > > Так это blocker тогда... Кстати, ещё, как вариант: > /usr/sbin/makewhatis -u & Тогда уж "как вариант" - запуск mklocatedb после установки/удаления каждого пакета. Зачем это нужно?
(В ответ на комментарий №5) > (In reply to comment #4) > > Так это blocker тогда... Согласно http://www.altlinux.org/BugSeverityPolicy, ошибка с серьёзностью blocker "ломает не связанное с данным ПО (или даже всю систему), вызывает серьёзные потери данных, создаёт дыру в безопасности при установке пакета". В долгом выполнении постустановочного скрипта нет ничего опасного и он не ломает другое ПО. По этой причине я считаю, что это не blocker, а скорее minor (возможно, normal).
apt-get после такого облома работать перестает. достаточно для "ломает всю систему"?
(In reply to comment #7) > По этой причине я считаю, что это не blocker, а скорее minor про "долго" - это попутный ворос. Главное - это то, что Шигорин в #4 написал.
(In reply to comment #6) > Тогда уж "как вариант" - запуск mklocatedb после установки/удаления каждого > пакета. Зачем это нужно? Я не занимался анализом ситуации на тему "зачем". Это пусть мантейнер думает. А вот вопрс "как" мне интересен.
(В ответ на комментарий №8) > apt-get после такого облома работать перестает. достаточно для "ломает всю > систему"? К сожалению, нет, так как система в которой удален файл /etc/cron.daily/makewhatis не является типичной. Если так мешает этот скрипт, то можно его сделать пустым ;) Тогда и апгрейд будет работать и makewhatis не будет долго выполняться.
к сожалению да, т.к. для /etc/cron.daily/makewhatis совершенно нормально выход с 1, что дает тот же результат что и его отсутствие
(В ответ на комментарий №12) > к сожалению да, т.к. для /etc/cron.daily/makewhatis совершенно нормально выход > с 1, что дает тот же результат что и его отсутствие Согласно коду с 1 он выходит, только если уже запущен и его пытаются запускать вновь. На моей машине этого ни разу не было, возможно, что на системах с несколькими процессорами это имеет место быть. Валер, я могу добавить ||: в %post, это тебя устроит? Выносить вызов makewhatis из скрипта не хочется, по той причине, что там есть дополнительная логика (например, скрипт не запускается при установке системы и при установке в хашере) и её придётся тогда тоже за собой тащить, а по пути есть шанс что-нибудь сломать :( Если основные претензии к тому что makewhatis долго выполняется, то это уже пожелание к пакету man, чтобы ускорить выполнение этого скрипта.
(In reply to comment #13) > Валер, я могу добавить ||: в %post, это тебя устроит? Меня вот -- да. > Выносить вызов makewhatis из скрипта не хочется, по той причине, что там есть > дополнительная логика (например, скрипт не запускается при установке системы и > при установке в хашере) и её придётся тогда тоже за собой тащить, а по пути > есть шанс что-нибудь сломать :( Ввиду bug #21838 предлагаю завернуть в проверку с опосредованием имени скрипта через переменную, чтоб не ругалось при отсутствии makewhatis и не тащило содержащий его пакет.
(В ответ на комментарий №14) > Ввиду bug #21838 предлагаю завернуть в проверку с опосредованием имени скрипта > через переменную, чтоб не ругалось при отсутствии makewhatis и не тащило > содержащий его пакет. Вроде такого? MAKEWHATIS=/etc/cron.daily/makewhatis if [ -x "$MAKEWHATIS" ]; then $MAKEWHATIS || : fi
(In reply to comment #15) > Вроде такого? Почти -- эта конструкция может вернуть non-zero при невыполнении теста, и если будет последней в %post -- то rpm сочтёт процесс завершившимся с ошибкой. Обычно либо инвертируют тест/действие ([ ! -x ] || ...), ну или можно и if заткнуть: MAKEWHATIS=/etc/cron.daily/makewhatis if [ -x "$MAKEWHATIS" ]; then $MAKEWHATIS || : fi || :
А, всё-таки, почему бы & не использовать ? Результат-то не важен, пусть в фоне шуршит и не тормозит процесс установки.
%post [ -n "$DURING_INSTALL" ] || su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis -u' ||: это простой вариан, можно еще добавить lock файл
Нужно отделить мух от котлет и признать, что скрипт для cron и post-script - это разные вещи, и не пытать на^Wобмануть судьбу и не "скрещивать ежа с ужом"
(В ответ на комментарий №18) > %post > [ -n "$DURING_INSTALL" ] || su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis > -u' ||: > > это простой вариан, можно еще добавить lock файл Надо ещё учесть переменную $FAKEROOTKEY (см. bug #11488)
[ -n "$DURING_INSTALL" -o -n "$FAKEROOTKEY" ] ||
%post if [ -z "$DURING_INSTALL" -o -z "$FAKEROOTKEY" ]; then su -l cacheman -s /bin/sh -c '/usr/sbin/makewhatis -u' ||: fi вот тебе практически окончательный вариант
Я очень прошу: не вызывайте makewhatis из %post вообще. Это в корне не правильное решение... не важно с какой обвязкой вокруг этой утилиты это делается. База whatis строится/обновляется из другого места. Если так хочется иметь обновлённую базу whatis прямо немедленно после установки rpm пакета, содержащего man-страницы, то лучше придумать триггер для rpm. Но в _любом_ случае обновление базы это не забота пакета с man-страницами.
(In reply to comment #23) > Если так хочется иметь обновлённую базу whatis прямо немедленно после установки > rpm пакета, содержащего man-страницы, то лучше придумать триггер для rpm. Это тоже да, но вроде уже прозвучало же? (насколько понимаю, предложенный кусочек кода лучше как раз закинуть в posttrans filetrigger в пакете man)
(В ответ на комментарий №24) > Это тоже да, но вроде уже прозвучало же? (насколько понимаю, предложенный > кусочек кода лучше как раз закинуть в posttrans filetrigger в пакете man) Возможно проглядел, если прозвучало, то отлично. В любом случае, в контексте этой баги, НЕ нужно вызывать makewhatis вообще никаким образом из этого пакета а равно и из других пакетов с манами.
(В ответ на комментарий №23) > Я очень прошу: не вызывайте makewhatis из %post вообще. Это можно будет сделать когда в rpm появится соответствующий триггер. Вопрос в том когда он появится?
(В ответ на комментарий №26) > Это можно будет сделать когда в rpm появится соответствующий триггер. Вопрос в > том когда он появится? Это нужно сделать безотносительно того, когда появится триггер.
(В ответ на комментарий №27) > Это нужно сделать безотносительно того, когда появится триггер. У нас вызов makewhatis уже несколько лет как во всех man-pages используется и я не вижу причины почему не стОит подождать ещё неделю-другую/месяц-два до появления триггеров.
(В ответ на комментарий №28) > У нас вызов makewhatis уже несколько лет как во всех man-pages используется и я > не вижу причины почему не стОит подождать ещё неделю-другую/месяц-два до > появления триггеров. Несколько лет во всех man-pages занимались не своим делом. Я не вижу причин этим пакетам продолжать это делать. Как подтверждение - сама эта бага.
А можно, пока, добавить ||: ? Снимем blocker и продолжайте спокойно спорить. :-)
не можно, ибо не нужно
Господа, завышение важности бага, в данном случае, не ускорит решение проблемы.
да нет, оно blocker, т.к. легко загоняет apt в нерабочее состояние
(В ответ на комментарий №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, т.к. обе переменные должны быть пустыми. Сделаю в следующей сборке, чтобы наконец уже закрыть этот баг. Когда появятся триггеры -- уберу совсем.
(В ответ на комментарий №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 вообще не нужно что бы Вы это поняли? > Когда появятся триггеры -- уберу совсем. их кто то обещал?
(В ответ на комментарий №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@-ом эту проблему. (Но это будет уже другая проблема и другой баг.)
(В ответ на комментарий №36) > > да нет, там -o, а не -a > > Поясни, пожалуйста, почему? DURING_INSTALL и FAKEROOTKEY решают разные задачи и используются в совершенно разных местах > > сколько раз нужно еще повторить что вызывать makewhatis вообще не нужно что бы > > Вы это поняли? > > Мне не нужно повторять, я это понял. Но пока нет триггеров, если убрать ручной > вызов makewhatis, то маны перестанут индексироваться и apropos/whatis > перестанут работать. см. https://bugzilla.altlinux.org/show_bug.cgi?id=21793 > Поэтому до появления триггеров, я не буду убирать вызов > makewhatis. Сейчас я могу заменить вызов кроновского скрипта на код, > приведённый выше, который ты предложил. Тебя это устроит? возможно это устроит apt > > > Когда появятся триггеры -- уберу совсем. man-pages-ru я давно вынес, видимо придется избавиться и от этого
(In reply to comment #36) > Мне не нужно повторять, я это понял. Но пока нет триггеров, если убрать ручной > вызов makewhatis, то маны перестанут индексироваться и apropos/whatis > перестанут работать. Ну почему -- cron-скрипт пока есть, когда-то да отработает. > Поэтому до появления триггеров, я не буду убирать вызов makewhatis. Убери, пожалуйста -- это исправит больше, чем сломает. Сейчас есть риск сломать apt (я тоже напоролся), а пользователи apropos должны быть достаточно сообразительны, чтоб при крайней нужде и руками его запустить (или перекронить, или сделать наконец этот файлтриггер). 2 shrek: тебе действительно охота быть местным Al Viro?
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)
