В Пнд, 08/09/2008 в 19:15 +0400, Yuri N. Sedunov пишет:
> В Пнд, 08/09/2008 в 18:46 +0400, Dmitry V. Levin пишет:
> > On Mon, Sep 08, 2008 at 06:42:10PM +0400, Yuri N. Sedunov wrote:
> > > В Пнд, 08/09/2008 в 18:23 +0400, Dmitry V. Levin пишет:
> > > > On Mon, Sep 08, 2008 at 06:18:03PM +0400, Yuri N. Sedunov wrote:
> > > > > В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> > > > > > On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > > > > > > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > > > > > > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > > > > > > релиза дистрибутива).
> > > > > > > 
> > > > > > > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > > > > > > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > > > > > > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > > > > > > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > > > > > > файловой системе).
> > > > > > 
> > > > > > Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> > > > > > ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> > > > > > библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> > > > > > 
> > > > > > Лучше исправить libgtk+2, чем городить объезды вокруг.
> > > > > 
> > > > > Нет, -- механизм работает и отказываться от него не надо.
> > > > 
> > > > Механизм работает, но при этом содержит серьёзный архитектурный изъян,
> > > > из-за которого возникают проблемы.
> > > 
> > > Проблемы возникают, если иконок нет в caсhe. Если gtk будет искать
> > > отсутствующие в caсhe, получаются те же "a lot of system call and disk
> > > seek overhead". Мне представляется поведение gtk логичным. 
> > 
> > А если ld-linux.so не будет запускать ELF'ы после смены soname до запуска
> > ldconfig'а, разве это тоже будет логично?
> 
> Давай не все в одну кучу сваливать,  А то договоримся, что,
> например, .schemas не надо устанавливать, а надо GConf научить
> шерстить  /etc/gconf/schemas/ в поисках нужного ключа и самому обновлять
> свою базу.
> 
> > > > > "GTK+ can use the cache files created by gtk-update-icon-cache to avoid
> > > > > a lot of system call and disk seek overhead when the application starts.
> > > > > Since the format of the cache files allows them to be mmap()ed shared
> > > > > between multiple applications, the overall memory consumption is reduced
> > > > > as well."
> > > > 
> > > > Из утверждения о том, что cache ускоряет работу, не следует, что cache
> > > > априори содержит более достоверную информацию, чем файлы, из которых он
> > > > построен.  Всякий cache нужно правильно invalidate'ить.
> > > 
> > > Как нужно правильно
> > > invalidate'ить /usr/share/icons/hicolor/icon-theme.cache?
> > 
> > Полагаю, надо искать файл по файловой системе, ЕСЛИ его не нашлось
> > в icon-theme.cache
> 
> Это предложение равносильно тому, чтобы не использовать icon-theme.cache
> совсем.  
Не равносильно. Если иконка существует в кэше, она оттуда будет (быстро)
взята. А вот если её нет... 
В принципе, если воспринимать icon-theme.cache не как кэш, а poor-man's
прокси-сервер, поставляющий иконки, то его действительно нужно обновлять
при каждой установке иконок и брать иконки только оттуда. Либо патчить
Gtk+ на предмет того, чтобы она обращалась с ним действительно как с
кэшом. Но тогда, извините, нужно ещё, чтобы Gtk+ кэшировала найденные
иконки. А то иначе какой-то однобокий кэш получается.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team