А что предлагается взамен? Просто вызывать /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)