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

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 9778 bytes --]

Напомню, что filetriggers -- это скрипты /usr/lib/rpm/*.filetrigger,
которые запускаются после успешного завершения транзакции.  Они получают
на вход список файлов, затронутых транзакцией (построчно на stdin),
то есть как бы вывод 'rpm -ql' от вновь установленных, обновлённых
и удалённых пакетов.  Механизм специально сделан максимально упрощенным
(дополнительную информацию можно получить естественным образом --
например, чтобы определить, был ли файл добавлен/обновлен или же удалён,
можно использовать простой тест типа [ -f "$f"] ).

* * *

Посмотрим, какой расклад мы имеем с кешем 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 лишние файлы, без которых, строго говоря, можно
обойтись.  На что мы можем парировать позитивной интерпретацией: кеш
иконок работает "из коробки" (а в противном случае возможны проблемы
с инвалидацией кеша, то есть битые иконки в приложениях).

* * *

Хотя принцип правильной группировки файлов не всегда можно толковать
однозначно, на практике он имеет большое значение.  Приведу пример
пакета, в котором принцип правильной группировки файлов между пакетами
явно нарушен -- это пакет libtcl.  Tcl может использоваться как embedded
language, т.е. приложения пишут обёртку для libtcl и дальше Tcl как язык
может использоваться внутри приложения.  Такие приложения получают
зависимость на libtcl soname.

Напишем простейшую программу, которая встраивает libtcl.

$ cat test.c
#include <tcl.h>
int main(int argc, char **argv)
{
        Tcl_Main(argc,argv,Tcl_Init);
        return 0;
}
$ gcc -Wall test.c -o test -ltcl
$

Теперь посмотрим, будет ли она работать в среде, где установлена
одна только библиотека libtcl.

$ hsh --init
$ hsh-install 
...
$ hsh-install libtcl
<13>Sep  9 23:05:07 rpmi: libtcl-8.5.4-alt1 installed
$ cp -pv ./test ~tmp/build/chroot/.in/ && hsh-run ./test
`./test' -> `/tmp/.private/at/build/chroot/.in/test'
application-specific initialization failed: Can't find a usable init.tcl in the following directories: 
    /usr/share/tcl/tcl8.5 /lib/tcl8.5 /lib/tcl8.5 /library /library /tcl8.5.4/library /tcl8.5.4/library
This probably means that Tcl wasn't installed properly.
$ 

Увы.  Приложения, слинковавшиеся с libtcl, громко обломятся (с диагностикой
"Tcl wasn't installed properly"!).  Если же установить пакет tcl, то уже
всё работает.

$ cp -pv ./test ~tmp/build/chroot/.in/ && hsh-run ./test && echo $? 
`./test' -> `/tmp/.private/at/build/chroot/.in/test'
0
$

Библиотека libtcl имеет "непрозрачную" зависимость на init.tcl, этот
файл загружается при инициализации библиотеки.  Без init.tcl приложения,
слинованные c libtcl, обламываются; а файл init.tcl имеет смысл только
в связи с наличием конкретной библиотеки libtcl.  Это достаточное
основание для того, чтобы применить принцип правильной группировки
файлов между пакетами -- файлы libtcl*so* и init.tcl должны быть
запакованы в один и тот же пакет.  На практике возможны два решения:
либо перенести init.tcl (и, возможно, ещё некоторые файлы) из пакета tcl
в пакет libtcl, либо полностью внести libtcl в tcl (то есть исключить
отдельный пакет с библиотекой, если библиотека "сама по себе"
не работает).

* * *

Вернёмся к кешу иконок libgtk+2 и его специфике.  Кеш создаётся для
каждой отдельной "темы" иконок, а темы раскладываются по отдельным
каталогам.  Для каждой темы должен существовать файл index.theme
(для темы "hicolor", используемой по умолчанию, это будет
/usr/share/icons/hicolor/index.theme в пакете icon-theme-hicolor).
Программа gtk-update-icon-cache по умолчанию отказывается создавать 
кеш, если отсутствует файл index.theme.

Однако пакет libgtk+2 не имеет зависимости на icon-theme-hicolor,
то есть в базовой установке для дефолтной темы hicolor отсутствует файл
index.theme.  Хотелось бы выяснить, в какой степени файл index.theme
реально необходим для использования иконок (и для создания кеша иконок).

Кроме того, тема hicolor является "расширяемой", т.е. пакеты приложений
кладут свои дополнительные иконки в /usr/share/icons/hicolor.  Остальные
темы являются как бы замкнутыми и независимыми (например, всё содержимое
каталога /usr/share/icons/gnome принадлежит пакету gnome-icon-theme,
а другие приложения туда иконок не кладут.

Короче, для триггера возможна следующая логика обновления кеша иконок:
1) каталог /usr/share/icons/hicolor обрабатывается специально;
2) остальные темы обрабатываются по факту наличия в траназкции файла
index.theme.

Тогда возможна следующая реализация /usr/lib/rpm/gtk-icon-cache.filetrigger:
	#!/bin/sh
	hicolor=
	while read -r f; do
		case "$f" in
			/usr/share/icons/hicolor/*)
				hicolor=1
				;;
			/usr/share/icons/*/index.theme)
				if [ -f "$f" ]; then
					gtk-update-icon-cache "${f%/*}"
				else
					rm -f "${f%/*}"/icon-theme.cache
				fi
				;;
		esac
	done
	if [ -n "$hicolor" ]; then
		gtk-update-icon-cache --ignore-theme-index /usr/share/icons/hicolor
	fi

То есть для любых изменений в /usr/share/icons/hicolor вызывается
gtk-update-icon-cache с опцией --ignore-theme-index (отключается
проверка наличия index.theme).  Все остальные темы обрабатываются по
файлу index.theme: если он добавился или обновился, то gtk-update-icon-cache
запускается обычным способом; если же файл index.theme удалился, то
удаляется и соответствующий ему кеш icon-theme.cache.

Мы исходили из предположения, что все остальные темы, кроме hicolor,
являются замкнутыми и независимыми, поэтому обновления кеша этих тем
можно привязать к соответствующему файлу index.theme.  Я сейчас на
всякий случай проверил, и оказалось, что предположение не всегда
выполняется.

$ grep /usr/share/icons/gnome/ ~tmp/build/cache/contents/contents_index_all |awk '$2!="gnome-icon-theme"'
/usr/share/icons/gnome/32x32    /usr/share/icons/gnome/32x32
/usr/share/icons/gnome/32x32/apps       /usr/share/icons/gnome/32x32/apps
/usr/share/icons/gnome/48x48    /usr/share/icons/gnome/48x48
/usr/share/icons/gnome/48x48/apps       /usr/share/icons/gnome/48x48/apps
/usr/share/icons/gnome/48x48/mimetypes  gdesklets
/usr/share/icons/gnome/48x48/mimetypes/gnome-mime-application-x-anjuta.png      anjuta2
/usr/share/icons/gnome/48x48/mimetypes/gnome-mime-application-x-codeblocks-workspace.png        codeblocks
/usr/share/icons/gnome/48x48/mimetypes/gnome-mime-application-x-codeblocks.png  codeblocks
/usr/share/icons/gnome/48x48/mimetypes/gnome-mime-application-x-gdesklets-display.png   gdesklets
/usr/share/icons/gnome/48x48/mimetypes/gnome-mime-application-x-littlewizard.png        littlewizard
/usr/share/icons/gnome/48x48/mimetypes/gnome-mime-application-x-ptoptimizer-script.png  hugin
/usr/share/icons/gnome/scalable/mimetypes/gnome-mime-application-x-anjuta.svg   anjuta2
/usr/share/icons/gnome/scalable/mimetypes/gnome-mime-application-x-littlewizard.svg     littlewizard
$ 

То есть существуют приложения, хотя и немногочисленные, которые кладут
иконки в тему "gnome".  По-видимому, в таких случаях кеш темы gnome
также следует обновлять; так что предложенная логика обновления
дополнительных тем уже оказывается недостаточной.

* * *

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

%post
find /usr/share/icons -type f |/usr/lib/rpm/gtk-icon-cache.filetrigger

То есть мы запускаем триггер от имени %post-скрипта и как бы говорим
ему: "посмотри, все эти иконки как будто только что добавились".
Дальше триггер уже сам решит, какие там есть темы и как обновлять кеш.

А при окончательном удалении библиотеки libgtk+2 кеш иконок больше
никому не нужен.  Так что можно написать

%postun
if [ $1 = 0 ]; then
	rm -f /usr/share/icons/*/icon-theme.cache
fi

* * *

Что до самой библиотеки libgtk+2, то, во-первых, недавно вышла новая
версия 2.14.  Во-вторых, мне не нравится существующий распил на libgtk+2
и libgtk+2-common.  Может быть, вместе с триггером я бы посмотрел новую
версию и попилил бы её на свой вкус.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

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, запакованной без вспомогательных инструментов
обновления этого кэша, есть вполне понятный смысл.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Led]

On Wednesday, 10 September 2008 00:04:08 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, запакованной без вспомогательных инструментов
> обновления этого кэша, есть вполне понятный смысл.
>
> Тоже самое, наверное, можно сказать и про libtcl.

Врядли. Там ещё кроме названных at@ есть "тщательно разложенные и 
замаскированные грабли":
https://bugzilla.altlinux.org/show_bug.cgi?id=16657

-- 
Led

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

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 в сборочной среде только для
> линковки, но не для запуска настоящих приложений?  Ну, по-моему,
> это очень специфический паттерн использования разделяемых библиотек,
> хотя нам он и кажется распространенным. :)

Я думаю, что этот "очень специфический паттерн использования разделяемых
библиотек" широко распространён в наших узких кругах.  Поэтому давайте
будем паковать вспомогательные инструменты, обслуживающие кэш иконок,
отдельно от библиотеки.  Тем более что это ничего по существу дела
поддержки кэша иконок не меняет.

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

Там используется конструкция, отличная от традиционной для библиотек
формы -ltcl?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
[skipped]
 > * * *

 > Хотя принцип правильной группировки файлов не всегда можно толковать
 > однозначно, на практике он имеет большое значение.  Приведу пример
 > пакета, в котором принцип правильной группировки файлов между пакетами
 > явно нарушен -- это пакет libtcl.  Tcl может использоваться как embedded
 > language, т.е. приложения пишут обёртку для libtcl и дальше Tcl как язык
 > может использоваться внутри приложения.  Такие приложения получают
 > зависимость на libtcl soname.

 > Напишем простейшую программу, которая встраивает libtcl.

[skipped]

 > Библиотека libtcl имеет "непрозрачную" зависимость на init.tcl, этот
 > файл загружается при инициализации библиотеки.  Без init.tcl приложения,
 > слинованные c libtcl, обламываются; а файл init.tcl имеет смысл только
 > в связи с наличием конкретной библиотеки libtcl.  Это достаточное
 > основание для того, чтобы применить принцип правильной группировки
 > файлов между пакетами -- файлы libtcl*so* и init.tcl должны быть
 > запакованы в один и тот же пакет.  На практике возможны два решения:
 > либо перенести init.tcl (и, возможно, ещё некоторые файлы) из пакета tcl
 > в пакет libtcl, либо полностью внести libtcl в tcl (то есть исключить
 > отдельный пакет с библиотекой, если библиотека "сама по себе"
 > не работает).

библиотека "сама по себе" работает, если приложение, в которое
встроена libtcl, потрудится установить в своё окружение переменную
TCL_LIBRARY, указывающую на специфический init.tcl -- например.
Есть и другие способы, желающие да насладятся разбором исходников tcl,
в районе generic/tclInterp.c и unix/tclUnix.Init.c

Кроме того, я был бы признателен, если бы ты избирал для иллюстрации
своих, безусловно, интересных размышлений более подходящие примеры.

[rest skipped]

-- 

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Led]

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

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3835 bytes --]

On Wed, Sep 10, 2008 at 01:37:33AM +0400, Sergey Bolshakov wrote:
>  > Библиотека libtcl имеет "непрозрачную" зависимость на init.tcl, этот
>  > файл загружается при инициализации библиотеки.  Без init.tcl приложения,
>  > слинованные c libtcl, обламываются; а файл init.tcl имеет смысл только
>  > в связи с наличием конкретной библиотеки libtcl.  Это достаточное
>  > основание для того, чтобы применить принцип правильной группировки
>  > файлов между пакетами -- файлы libtcl*so* и init.tcl должны быть
>  > запакованы в один и тот же пакет.  На практике возможны два решения:
>  > либо перенести init.tcl (и, возможно, ещё некоторые файлы) из пакета tcl
>  > в пакет libtcl, либо полностью внести libtcl в tcl (то есть исключить
>  > отдельный пакет с библиотекой, если библиотека "сама по себе"
>  > не работает).
> 
> библиотека "сама по себе" работает, если приложение, в которое
> встроена libtcl, потрудится установить в своё окружение переменную
> TCL_LIBRARY, указывающую на специфический init.tcl -- например.
> Есть и другие способы, желающие да насладятся разбором исходников tcl,
> в районе generic/tclInterp.c и unix/tclUnix.Init.c
> 
> Кроме того, я был бы признателен, если бы ты избирал для иллюстрации
> своих, безусловно, интересных размышлений более подходящие примеры.

$ hsh --init
<86>Sep 10 01:49:26 userdel[31245]: delete user `rooter'
<86>Sep 10 01:49:26 userdel[31245]: remove group `rooter'
<86>Sep 10 01:49:26 groupadd[31246]: new group: name=rooter, gid=505
<86>Sep 10 01:49:26 useradd[31247]: new user: name=rooter, uid=505, gid=505, home=/root, shell=/bin/bash
<86>Sep 10 01:49:26 userdel[31249]: delete user `builder'
<86>Sep 10 01:49:26 userdel[31249]: remove group `builder'
<86>Sep 10 01:49:26 groupadd[31250]: new group: name=builder, gid=506
<86>Sep 10 01:49:26 useradd[31251]: new user: name=builder, uid=506, gid=506, home=/usr/src, shell=/bin/bash
$ hsh-install xauth
<13>Sep 10 01:49:35 rpmi: libX11-locales-3:1.1.5-alt1 installed
<13>Sep 10 01:49:35 rpmi: libXau-1.0.4-alt1 installed
<13>Sep 10 01:49:36 rpmi: libXdmcp-1.0.2-alt1.0 installed
<13>Sep 10 01:49:36 rpmi: libxcb-1.1-alt4 installed
<13>Sep 10 01:49:36 rpmi: libX11-3:1.1.5-alt1 installed
<13>Sep 10 01:49:36 rpmi: libXext-1.0.4-alt1 installed
<13>Sep 10 01:49:36 rpmi: libICE-1.0.4-alt1 installed
<13>Sep 10 01:49:36 rpmi: libSM-1.1.0-alt1 installed
<13>Sep 10 01:49:36 rpmi: libXt-1.0.5-alt1 installed
<13>Sep 10 01:49:36 rpmi: libXmu-1.0.4-alt1 installed
<13>Sep 10 01:49:36 rpmi: xauth-1:1.0.3-alt1 installed
$ hsh-install ocamlbrowser
<13>Sep 10 01:49:44 rpmi: ocaml-runtime-3.10.2-alt3.1 installed
<13>Sep 10 01:49:44 rpmi: libtcl-8.5.4-alt1 installed
<13>Sep 10 01:49:44 rpmi: libXrender-0.9.4-alt1 installed
<13>Sep 10 01:49:44 rpmi: libexpat-2.0.1-alt0.1 installed
<13>Sep 10 01:49:44 rpmi: libfreetype-2.3.7-alt1 installed
<13>Sep 10 01:49:44 rpmi: fontconfig-2.6.0-alt1 installed
Updating fonts cache: <29>Sep 10 01:49:46 fontconfig: Updating fonts cache: succeeded
[ DONE ]
<13>Sep 10 01:49:46 rpmi: libXft-2.1.13-alt1 installed
<13>Sep 10 01:49:46 rpmi: libXScrnSaver-1.1.3-alt1 installed
<13>Sep 10 01:49:46 rpmi: libtk-8.5.4-alt1 installed
<13>Sep 10 01:49:46 rpmi: labltk-runtime-3.10.2-alt3.1 installed
<13>Sep 10 01:49:46 rpmi: rpm-build-ocaml-1.1.1-alt1 installed
<13>Sep 10 01:49:56 rpmi: ocaml-3.10.2-alt3.1 installed
<13>Sep 10 01:49:59 rpmi: ocamlbrowser-3.10.2-alt3.1 installed
$ hsh-run -X ocamlbrowser
xauth:  creating new authority file /usr/src/.Xauthority
Fatal error: exception Protocol.TkError("Can't find a usable init.tcl in the following directories: 
    /usr/share/tcl/tcl8.5 /usr/lib/tcl8.5 /lib/tcl8.5 /usr/library /library /tcl8.5.4/library /tcl8.5.4/library

This probably means that Tcl wasn't installed properly.
")
$ 

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > On Wed, Sep 10, 2008 at 01:37:33AM +0400, Sergey Bolshakov wrote:
 >> > Библиотека libtcl имеет "непрозрачную" зависимость на init.tcl, этот
 >> > файл загружается при инициализации библиотеки.  Без init.tcl приложения,
 >> > слинованные c libtcl, обламываются; а файл init.tcl имеет смысл только
 >> > в связи с наличием конкретной библиотеки libtcl.  Это достаточное
 >> > основание для того, чтобы применить принцип правильной группировки
 >> > файлов между пакетами -- файлы libtcl*so* и init.tcl должны быть
 >> > запакованы в один и тот же пакет.  На практике возможны два решения:
 >> > либо перенести init.tcl (и, возможно, ещё некоторые файлы) из пакета tcl
 >> > в пакет libtcl, либо полностью внести libtcl в tcl (то есть исключить
 >> > отдельный пакет с библиотекой, если библиотека "сама по себе"
 >> > не работает).
 >> 
 >> библиотека "сама по себе" работает, если приложение, в которое
 >> встроена libtcl, потрудится установить в своё окружение переменную
 >> TCL_LIBRARY, указывающую на специфический init.tcl -- например.
 >> Есть и другие способы, желающие да насладятся разбором исходников tcl,
 >> в районе generic/tclInterp.c и unix/tclUnix.Init.c
 >> 
 >> Кроме того, я был бы признателен, если бы ты избирал для иллюстрации
 >> своих, безусловно, интересных размышлений более подходящие примеры.

 > $ hsh --init
[skipped]

 > $ hsh-run -X ocamlbrowser
 > xauth:  creating new authority file /usr/src/.Xauthority
 > Fatal error: exception Protocol.TkError("Can't find a usable init.tcl in the following directories: 
 >     /usr/share/tcl/tcl8.5 /usr/lib/tcl8.5 /lib/tcl8.5 /usr/library /library /tcl8.5.4/library /tcl8.5.4/library

 > This probably means that Tcl wasn't installed properly.
 > ")
 > $ 

Что же это иллюстрирует ?
На мой взгляд, неполные зависимости в ocamlbrowser.

Бишь, в ответ на моё разъяснение, каким именно способом _возможно_
использовать libtcl без tcl, ты продолжаешь меня уверять, что если
ничего этакого в приложении не делается, то оно и не работает -- ну
так я этого и не оспариваю.

Для выделения libtcl в отдельный подпакет мне было достаточно
знания того, что такие способы существуют и практикуются.
Что должно значиться в зависимостях некоего пакета Пэ,
слинкованного с libtcl -- решать уважаемому майнтайнеру Пэ,
не мне.

-- 

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

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]

On Wed, Sep 10, 2008 at 02:10:08AM +0400, Sergey Bolshakov wrote:
>  >> библиотека "сама по себе" работает, если приложение, в которое
>  >> встроена libtcl, потрудится установить в своё окружение переменную
>  >> TCL_LIBRARY, указывающую на специфический init.tcl -- например.
>  >> Есть и другие способы, желающие да насладятся разбором исходников tcl,
>  >> в районе generic/tclInterp.c и unix/tclUnix.Init.c
>  >> 
>  >> Кроме того, я был бы признателен, если бы ты избирал для иллюстрации
>  >> своих, безусловно, интересных размышлений более подходящие примеры.
> 
>  > $ hsh --init
> [skipped]
> 
>  > $ hsh-run -X ocamlbrowser
>  > xauth:  creating new authority file /usr/src/.Xauthority
>  > Fatal error: exception Protocol.TkError("Can't find a usable init.tcl in the following directories: 
>  >     /usr/share/tcl/tcl8.5 /usr/lib/tcl8.5 /lib/tcl8.5 /usr/library /library /tcl8.5.4/library /tcl8.5.4/library
> 
>  > This probably means that Tcl wasn't installed properly.
>  > ")
>  > $ 
> 
> Что же это иллюстрирует ?

Просили более подходящий пример для иллюстрации, нежели чем макетная
программа.  Есть реальный пример, который иллюстрирует проблему.

> На мой взгляд, неполные зависимости в ocamlbrowser.

Что же, в ocamlbrowser нужно добавить зависимость на tcl(init)?
Но ведь эта зависимость "сидит" в бинарном коде libtcl.

На самом деле tcl не предоставляет зависимость вида tcl(init),
так что даже нет хорошего способа указать именно эту зависимость.
Как тогда предлагается дополнить зависимости ocamlbrowser?

> Бишь, в ответ на моё разъяснение, каким именно способом _возможно_
> использовать libtcl без tcl, ты продолжаешь меня уверять, что если
> ничего этакого в приложении не делается, то оно и не работает -- ну
> так я этого и не оспариваю.
> 
> Для выделения libtcl в отдельный подпакет мне было достаточно
> знания того, что такие способы существуют и практикуются.
> Что должно значиться в зависимостях некоего пакета Пэ,
> слинкованного с libtcl -- решать уважаемому майнтайнеру Пэ,
> не мне.

$ nm -D /usr/lib64/ocaml/stublibs/dlllabltk.so |grep Tcl_Init
	U Tcl_Init
$

Вызов Tcl_Init приводит к облому, так что программы, "честно"
слинковавшиеся с libtcl, имеют недостаточные зависимости.

С одной стороны, программы, слинкованные с libtcl, могут и не
использовать Tcl_Init.  С другой стороны, можно ожидать, что
программы будут использовать именно эту стандартную процедуру
инициализации.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

[devel] Q: gtk-update-icon-cache index.theme

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

On Wed, Sep 10, 2008 at 12:23:45AM +0400, Alexey Tourbin wrote:
> Вернёмся к кешу иконок libgtk+2 и его специфике.  Кеш создаётся для
> каждой отдельной "темы" иконок, а темы раскладываются по отдельным
> каталогам.  Для каждой темы должен существовать файл index.theme
> (для темы "hicolor", используемой по умолчанию, это будет
> /usr/share/icons/hicolor/index.theme в пакете icon-theme-hicolor).
> Программа gtk-update-icon-cache по умолчанию отказывается создавать 
> кеш, если отсутствует файл index.theme.
> 
> Однако пакет libgtk+2 не имеет зависимости на icon-theme-hicolor,
> то есть в базовой установке для дефолтной темы hicolor отсутствует файл
> index.theme.  Хотелось бы выяснить, в какой степени файл index.theme
> реально необходим для использования иконок (и для создания кеша иконок).

Хотелось бы выяснить, в какой степени файл index.theme реально необходим
для использования иконок (и для создания кеша иконок).

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Alexey Shabalin]

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

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



-- 
Alexey Shabalin

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

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
[skipped]
 >> 
 >> > $ hsh-run -X ocamlbrowser
 >> > xauth:  creating new authority file /usr/src/.Xauthority
 >> > Fatal error: exception Protocol.TkError("Can't find a usable init.tcl in the following directories: 
 >> >     /usr/share/tcl/tcl8.5 /usr/lib/tcl8.5 /lib/tcl8.5 /usr/library /library /tcl8.5.4/library /tcl8.5.4/library
 >> 
 >> > This probably means that Tcl wasn't installed properly.
 >> > ")
 >> > $ 
 >> 
 >> Что же это иллюстрирует ?

 > Просили более подходящий пример для иллюстрации, нежели чем макетная
 > программа.  Есть реальный пример, который иллюстрирует проблему.

Проблема проиллюстрирована, а именно:
 >> На мой взгляд, неполные зависимости в ocamlbrowser.

 > Что же, в ocamlbrowser нужно добавить зависимость на tcl(init)?
 > Но ведь эта зависимость "сидит" в бинарном коде libtcl.
Нет, такой сущности, как tcl(init), не существует (во всяком случае
локализованной на файловой системе)

 > На самом деле tcl не предоставляет зависимость вида tcl(init),
 > так что даже нет хорошего способа указать именно эту зависимость.
 > Как тогда предлагается дополнить зависимости ocamlbrowser?
В этом конкретном случае (и, допускаю, в нескольких подобных)
зависимость на tcl должна быть выставлена руками.
 
 >> Бишь, в ответ на моё разъяснение, каким именно способом _возможно_
 >> использовать libtcl без tcl, ты продолжаешь меня уверять, что если
 >> ничего этакого в приложении не делается, то оно и не работает -- ну
 >> так я этого и не оспариваю.
 >> 
 >> Для выделения libtcl в отдельный подпакет мне было достаточно
 >> знания того, что такие способы существуют и практикуются.
 >> Что должно значиться в зависимостях некоего пакета Пэ,
 >> слинкованного с libtcl -- решать уважаемому майнтайнеру Пэ,
 >> не мне.

 > $ nm -D /usr/lib64/ocaml/stublibs/dlllabltk.so |grep Tcl_Init
 > 	U Tcl_Init
 > $

 > Вызов Tcl_Init приводит к облому, так что программы, "честно"
 > слинковавшиеся с libtcl, имеют недостаточные зависимости.

Есть масса _штатных_ способов повлиять на поведение Tcl_Init так, что
содержимое пакета tcl будет не нужно -- ты бы мог заглянуть наконец в
исходники и убедиться в этом.

 > С одной стороны, программы, слинкованные с libtcl, могут и не
 > использовать Tcl_Init.  С другой стороны, можно ожидать, что
 > программы будут использовать именно эту стандартную процедуру
 > инициализации.

Вот для этого у программ есть авторы и майнтайнеры.
В общем, я полагаю, обсуждать тут нечего.

-- 

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On Wed, Sep 10, 2008 at 01:52:57PM +0400, Sergey Bolshakov wrote:
[...]
>  > Что же, в ocamlbrowser нужно добавить зависимость на tcl(init)?
>  > Но ведь эта зависимость "сидит" в бинарном коде libtcl.
> Нет, такой сущности, как tcl(init), не существует (во всяком случае
> локализованной на файловой системе)
> 
>  > На самом деле tcl не предоставляет зависимость вида tcl(init),
>  > так что даже нет хорошего способа указать именно эту зависимость.
>  > Как тогда предлагается дополнить зависимости ocamlbrowser?
> В этом конкретном случае (и, допускаю, в нескольких подобных)
> зависимость на tcl должна быть выставлена руками.

А не слишком ли это рутинная задача для мантейнера, который привык к
автоматически проставляемым зависимостям?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Twas brillig at 14:01:17 10.09.2008 UTC+04 when ldv@altlinux.org did gyre and gimble:

 DVL> А не слишком ли это рутинная задача для мантейнера, который привык
 DVL> к автоматически проставляемым зависимостям?

Вывести автоматически, какой конкретно toplevel нужен данному пакету -
задача нетривиальная.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

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

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

On Wednesday 10 September 2008, Alexey Tourbin wrote:

[...]
> заключить, что библиотеку libgtk+2, программу
> gtk-update-icon-cache и триггер
> /usr/lib/rpm/gtk-icon-cache.filetrigger следует запаковать в один
> и тот же пакет (libgtk+2).
Не надо, а то от arepo никогда не откажемся.

[...]

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Michael Shigorin]

On Wed, Sep 10, 2008 at 05:08:16PM +0700, Mikhail Gusarov wrote:
> > А не слишком ли это рутинная задача для мантейнера, который
> > привык к автоматически проставляемым зависимостям?
> Вывести автоматически, какой конкретно toplevel нужен данному
> пакету - задача нетривиальная.

Возможно ли реализовать разумный дефолт, не отказывая при этом
желающим пальнуть в ногу?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Evgeny Sinelnikov]

10 сентября 2008 г. 17:50 пользователь Michael Shigorin
<mike@osdn.org.ua> написал:
> On Wed, Sep 10, 2008 at 05:08:16PM +0700, Mikhail Gusarov wrote:
>> > А не слишком ли это рутинная задача для мантейнера, который
>> > привык к автоматически проставляемым зависимостям?
>> Вывести автоматически, какой конкретно toplevel нужен данному
>> пакету - задача нетривиальная.
>
> Возможно ли реализовать разумный дефолт, не отказывая при этом
> желающим пальнуть в ногу?

а смысл? Я так понял, что зависимость есть, а библиотека не
работает... и каждый, кто по воле случая собирёт пакет линкующийся с
такой библиотекой, будет вынужден проставлять дополнительную не явную
зависимость. То есть каждый раз одни и те же грабли, при цене вопроса
в один файл...


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Q: gtk-update-icon-cache index.theme

[Yuri N. Sedunov]

В Срд, 10/09/2008 в 10:52 +0400, Alexey Tourbin пишет:
> On Wed, Sep 10, 2008 at 12:23:45AM +0400, Alexey Tourbin wrote:
> > Вернёмся к кешу иконок libgtk+2 и его специфике.  Кеш создаётся для
> > каждой отдельной "темы" иконок, а темы раскладываются по отдельным
> > каталогам.  Для каждой темы должен существовать файл index.theme
> > (для темы "hicolor", используемой по умолчанию, это будет
> > /usr/share/icons/hicolor/index.theme в пакете icon-theme-hicolor).
> > Программа gtk-update-icon-cache по умолчанию отказывается создавать 
> > кеш, если отсутствует файл index.theme.
> > 
> > Однако пакет libgtk+2 не имеет зависимости на icon-theme-hicolor,
> > то есть в базовой установке для дефолтной темы hicolor отсутствует файл
> > index.theme.  Хотелось бы выяснить, в какой степени файл index.theme
> > реально необходим для использования иконок (и для создания кеша иконок).
> 
> Хотелось бы выяснить, в какой степени файл index.theme реально необходим
> для использования иконок (и для создания кеша иконок).

Результат работы gtk-update-icon-cache не зависит от наличия
index.theme.

-- 
Yuri N. Sedunov