Re: [devel] gtk-update-icon-cache filetrigger (+ libtcl deficiency)

[Led <ledest@gmail.com>]

On Wednesday, 10 September 2008 00:45:37 Alexey Tourbin wrote:
> 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 в библиотечные пакеты.

Извините, что встреваю. Но... например, для того, чтобы 
libgtk+2-%version-%release.i586.rpm можно было поставить в x86_64 систему.

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



-- 
Led