[Gnome] Бета 4.1. на gnome. Обнаруженные баги.

[Игорь Андросов]

25 августа 2008 г. 13:16 пользователь Yuri N. Sedunov
<aris на altlinux.org> написал:
> В Вск, 24/08/2008 в 19:31 +0400, Yuri N. Sedunov пишет:
>> В Чтв, 21/08/2008 в 16:57 +0400, Yuri N. Sedunov пишет:
>> > В Втр, 19/08/2008 в 09:55 +0400, Юсупов Радик пишет:
>> > > Yuri N. Sedunov пишет:
>
> <skip>
>
>> Варианты лечения причин могут быть разные. Наименее трудоемким накануне
>> выхода дистрибутивов, видимо, будет такой, что позволит не потрошить
>> кучу пакетов.
>
> Можно, наверное, и робота послать потрошить кучу пакетов.
repocop на предмет содержания /usr/share/icons?
Макрос + полиси?

>> 1. Можно отказаться от использования gtk-update-icon-cache, исправить
>> пакеты, список которых приведен и успокоится до выхода диструбутивов.
>
> В 2005 году этот механизм не работал, почему и был выключен, хотя
> заготовки в libgtk2.spec так и есть с тех пор. Теперь работает, и
> отказываться от него не хочется. Причем gtk использовал бы кеши, будь
> они там, не только в /usr/share/icons/hicolor, но и для любых других
> наборов иконок в /usr/share/icons/, кеши иконок /usr/share/themes/*/
> и /usr/share/pixmaps.
Работает - это уже хорошо. То что нет четкой политики его
использования - плохо. Установка иконок после вызова update приводит к
невидимости этих иконок.

>> 2. можно изменить макросы %{update,clean}_desktopdb или
>> %{update,clean}_menus добавив в них вызов gtk-update-icon-cache и
>> пересобрать бранч.
>
> Не, все-таки, мне этот вариант не нравится.
Мне как-то тоже не очень.

Вообще какие у нас есть варианты обновления кэша. (Отвечая на
следующее письмо я за то что бы использовать этот механизм, так как
вызвать его может любой желающий, и потом будут проблемы, в виде
отсутсвующих иконок).
1. (Простой) Добавить в указанные макросы этот вызов. Минусы - вызов
обновления возможен до установки gtk, нет уверенности что при
попадании иконки в icons будут вызваны указанные макросы,
2. (Ленивый) Повесить этот скрипт на вход в X. Минус - до следующего
входа в X обновления не будет.
3. (Системный) Зацепить это обновление в крон (закомментированый и так
там есть). Минус - некоторое время не будет обновлен кэш, постоянный
вызов gtk-update-icon-cache.
4. (Безумный) Мониторить чем-нибудь каталог icons, при изменениях
вызывать gtk-update-icon-cache. Минус, постоянно какая-то фигня в
памяти болтается.
5. (Трудоемкий) Натравить repocop на пакеты на предмет содержания
контента /usr/share/icons, добавить макрос в rpm для вызова
gtk-update-icon-cache, сделать патчи для пакетов, дописать полиси.
Минус - много пакетов ворочать.

Это то что вижу я, у кого есть какие еще варианты? Какие еще кто минусы видит?

-- 
С уважением Игорь.

[ALT Linux Team]