From Fedora Project Wiki

m (1 revision(s))
m (Fixed template)
Line 1: Line 1:
{| border="1"
{{Draft}}
|-
| {{Template:Warning}} '''This is just a draft'''
|}


== Changelog ==
== Changelog ==

Revision as of 18:46, 3 June 2008

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Changelog

0.1: first try
0.2: simplify to xdg-utils (only) usage.
0.3: drop "if no existing dependent packages..."
0.4: xdg-utils applies only to F7+ Core packages
0.5: drop xdg-utils usage (Core NACK'd v0.4)
0.6: gtk2 icon cache coherency issues in separate section
0.7: use xdg-utils again (for abstraction, allows use of guic --delay)

Currently deadlocked. This proposal asserts that updating guildelines to strictly follow the icon-theme-spec and solving gtk icon cache coherency are independent problems, and that the latter is/should-be outside the scope of packaging guidlines. Core cabal disagrees, postponing ACK of this proposal pending resolution of gtk icon cache coherency issue first.

Existing Guideline

GTK+ icon cache

If an application installs icons into one of the subdirectories in %{_datadir}/icons/ (such as hicolor in the following examples), gtk-update-icon-cache should be run after the package is installed/uninstalled on FC4 and later. This is required so that the installed icons show up in GNOME menus right after package installation, and speeds up GTK+ applications' access to the icons. For KDE, just 'touch'ing the top-level icon directory is enough.

Note that no dependencies should be added for this. If gtk-update-icon-cache is not available, there's nothing that would be needing the cache update. Not adding the dependency on gtk-update-icon-cache (ie. gtk2 >= 2.6.0) makes it easier to use the package (or the same specfile) on systems where it's not available nor needed, such as older distro versions or (very) trimmed down installations.

%post
touch --no-create %{_datadir}/icons/hicolor || :
%{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :

%postun
touch --no-create %{_datadir}/icons/hicolor || :
%{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :


Proposal

Motivations for changing the existing guideline:

  • include footnote/reference to fdo icon-theme-spec.
  • simplify guideline by removing toolkit-specific optimization details.
  • gtk-update-icon-cache currently runs on every pkg install (that includes icons), which is potentially very inefficient. (see %posttrans). Informal benchmarks show 0.2-0.5 (user) seconds for every invocation. This appears to have been addressed in a recent update to guic to include a --delay option.

icon cache

If an application installs icons into one of the subdirectories in %{_datadir}/icons/ (such as hicolor in the following examples), care must be taken to ensure the installed icons appear properly after package installation[[FootNote([1] ) .

Use the following scriptlets:

%post
%{_bindir}/xdg-icon-resource forceupdate --theme hicolor 2> /dev/null || :

%postun
%{_bindir}/xdg-icon-resource forceupdate --theme hicolor 2> /dev/null || :

gtk icon cache coherency brainstorm (not part of packaging guidelines)

Brainstorming methods to keep gtk icon cache fresh. See also bugzilla bug tracking this:
[2] gtk2: create/maintain iconcache
Ideas include:

  • cron job (like prelink)
  • on boot (init) + file-system monitoring daemon (e.g. incron)
  • rpm %posttrans scriptlet hook. No, %posttransun doesn't work (rpm bug?)