On Wed, Sep 10, 2008 at 01:32:14AM +0400, Dmitry V. Levin wrote:
> On Wed, Sep 10, 2008 at 01:18:04AM +0400, Alexey Tourbin wrote:
> > On Wed, Sep 10, 2008 at 01:04:08AM +0400, Dmitry V. Levin wrote:
> [...]
> > > Существует как минимум один распространённый тип использования libgtk+2,
> > > при котором кэш иконок не используется совершенно: libgtk+2-devel.  Так
> > > что в библиотеке libgtk+2, запакованной без вспомогательных инструментов
> > > обновления этого кэша, есть вполне понятный смысл.
> > 
> > То есть это использование libgtk+2 в сборочной среде только для
> > линковки, но не для запуска настоящих приложений?  Ну, по-моему,
> > это очень специфический паттерн использования разделяемых библиотек,
> > хотя нам он и кажется распространенным. :)
> 
> Я думаю, что этот "очень специфический паттерн использования разделяемых
> библиотек" широко распространён в наших узких кругах.  Поэтому давайте
> будем паковать вспомогательные инструменты, обслуживающие кэш иконок,
> отдельно от библиотеки.  Тем более что это ничего по существу дела
> поддержки кэша иконок не меняет.

Оно уже "туда" запаковано.

$ rpm -qf /usr/bin/gtk-update-icon-cache 
libgtk+2-common-2.12.11-alt2
$ 

У меня просто стоял вопрос, куда паковать триггер (Юрий Седунов думал,
что его надо паковать в пакет rpm, а я здесь постарался объяснить, что
его нужно паковать туда, куда он относится, а не в rpm).

И всё равно я не понял, чем плохо паковать вспомогательные инструменты
типа gtk-update-icon-cache в библиотечные пакеты.  Ты не дал аргумента,
или же rationale ("существует распространенный тип использования" -- это
только предпосылка).  Очень плохо, если при установке в сборочный чрут
отработает gtk-update-icon-cache?  А то что ldconfig отработает это
хорошо, потому что кое-какие прграммы в чруте всё-таки запускаются,
а вот иконочный кеш скорее всего не потребуется...

> > > Тоже самое, наверное, можно сказать и про libtcl.
> > 
> > Нет, имеет место быть цепочка зависимостей
> > tcl-devel -> tcl -> libtcl
> 
> Там используется конструкция, отличная от традиционной для библиотек
> формы -ltcl?

С точки зрения минимизации сборочных зависимостей нет смысла отпиливать
libtcl от пакета tcl, т.к. сборочный пакет называется tcl-devel (а не
libtcl-devel) и он требует tcl.