fp-wiki>ImportUser (Imported from MoinMoin) |
(removing extra space) |
||
(5 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
== Changelog == | == Changelog == | ||
Line 63: | Line 58: | ||
* on boot (init) + file-system monitoring daemon (e.g. incron) | * on boot (init) + file-system monitoring daemon (e.g. incron) | ||
* rpm %posttrans scriptlet hook. No, %posttransun doesn't work (rpm bug?) | * rpm %posttrans scriptlet hook. No, %posttransun doesn't work (rpm bug?) | ||
[[Category:Archived packaging guideline drafts]] |
Latest revision as of 01:36, 11 July 2010
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?)