On Wed, Sep 10, 2008 at 01:04:08AM +0400, Dmitry V. Levin wrote:
> On Wed, Sep 10, 2008 at 12:23:45AM +0400, Alexey Tourbin wrote:
> [...]
> > Посмотрим, какой расклад мы имеем с кешем gtk2.  Библиотека libgtk+2
> > использует кеш по умолчанию, если он существует (это ускоряет запуск
> > приложений, а также экономит память, т.к. иконки расшариваются между
> > приложениями).  Есть стандартная программа обновления кеша
> > gtk-update-icon-cache.  Кроме библиотеки libgtk+2 этот кеш больше никто
> > не использует.
> > 
> > Следуя принципу правильной группировки файлов в пакетах, можно
> > заключить, что библиотеку libgtk+2, программу gtk-update-icon-cache
> > и триггер /usr/lib/rpm/gtk-icon-cache.filetrigger следует запаковать
> > в один и тот же пакет (libgtk+2).
> > 
> > Принцип правильной группировки файлов между пакетами состоит в том,
> > что совместно используемые файлы нужно паковать в один и тот же пакет.
> > Действительно, программа gtk-update-icon-cache сама по себе, по
> > отдельности, имеет мало смысла (т.к. результат её работы представляет
> > интерес только для библиотеки libgtk+2).  А триггер
> > /usr/lib/rpm/gtk-icon-cache.filetrigger, в свою очередь, сможет сделать
> > что-либо только при наличии программы gtk-update-icon-cache.  Короче,
> > эти две программы просто "обслуживают" библиотеку libgtk+2.
> > 
> > С другой стороны, этот принцип не является настолько однозначным, чтобы
> > можно было применять его механически.  Нужно думать.  Ведь библиотека
> > libgtk+2, хотя и использует кеш иконок по умолчанию, всё же обходится
> > без него, если кеш отсутствует.  Так что кто-то может возразить, что
> > мы кладём в libgtk+2 лишние файлы, без которых, строго говоря, можно
> > обойтись.  На что мы можем парировать позитивной интерпретацией: кеш
> > иконок работает "из коробки" (а в противном случае возможны проблемы
> > с инвалидацией кеша, то есть битые иконки в приложениях).
> 
> Существует как минимум один распространённый тип использования libgtk+2,
> при котором кэш иконок не используется совершенно: libgtk+2-devel.  Так
> что в библиотеке libgtk+2, запакованной без вспомогательных инструментов
> обновления этого кэша, есть вполне понятный смысл.

То есть это использование libgtk+2 в сборочной среде только для
линковки, но не для запуска настоящих приложений?  Ну, по-моему,
это очень специфический паттерн использования разделяемых библиотек,
хотя нам он и кажется распространенным. :)

> Тоже самое, наверное, можно сказать и про libtcl.

Нет, имеет место быть цепочка зависимостей
tcl-devel -> tcl -> libtcl