Bug#407837: gtk icon cache transition problems

[Loïc Minier]

        Hi Joey,

 and thanks for reopening this discussion.

On Sun, Jan 21, 2007, Joey Hess wrote:
> So currently, the first package that starts calling gtk-update-icon-cache
> will break all other packages that have icons in the same directory

 This is correct.

>  This means that there will be a large transition period to add the icon
>  cache updating flag.

 Yes.  And I didn't want to start this transition without usable
 packages during the time of the transition.

 Another common problem is that some people install from source and some
 upstream Makefiles will create the icon caches (or not update them).
 So, I think we need a way to turn off the icon cache during the
 transition and to debug broken systems.

 However, my initial crazy idea was this:

>                      I propose introducing a common postinst snipset in
>  a shared package (perhaps a desktop-common-postinst package or a
>  foobarhelper) where we could switch a flag on to switch to the gtk icon
>  cache world

 The reason I proposed this is that we often end with cruft or problems
 which would be easy to solve centrally, but which are a pain to solve
 in all packages (changing and rebuilding them, but especially at the
 same time in some cases like here).  You can look at this proposal like
 some sort runtime debhelper components.  I don't see this happening
 anytime soon though.  Out of curiosity: would you be interested in
 extending debhelper in this direction?

> 1. Modify the icon cache code to look for real files if there is a cache
>    miss. Then we would not need a flag day. 

 This was depicted as defeating the purpose of the cache.  It might be
 an acceptable solution during the transition.

> 2. Move icons to some other directory, and cache those in the new directory,
>    but not those in the old. Could be a problem since icon directories are
>    semi-standardised.

 Yep, not really an option.

> 3. Go with the flag idea suggested above.

 Just to make things perfectly clear, this refers to a flag in a common
 package which is pulled by all packages.  Another possibility for the
 flag is to be a Gtk setting, perhaps we can make this 3-b; option 3-b
 might be feasible in a shorter time frame.

>                                           But examination of my system
>    suggests that some packages are already using gtk-update-icon-cache.
>    For example, I have a /usr/share/icons/hicolor/icon-theme.cache, last
>    updated Jul 30 2006, that must have been created by some rogue package.

 Yes, it's a big problem already.  It also happens frequently with
 people using Ubuntu packages at some point: the postrm will update the
 icon cache again, but not remove it...

 It's IMO incorrect to use gtk-update-icon-cache in shared directories
 in Debian at this point, and you can file serious bugs against package
 doing so; but it's fine to use it in private directories, such as
 packages shipping themes in a sub-directory.  This is why the utility
 is shipped in the Gtk package.

>    For the flag idea to be effective, it should completely disable use of
>    gtk-update-icon-cache on a directory, which suggests to me that
>    gtk-update-icon-cache itself should check for the flag.

 That's one way of seeing it, I think we could as well change libgtk; in
 fact I even started doing so against Gtk 2.8, but didn't finish the
 patch back then, and couldn't reuse my work against 2.10.

> 4. File bugs on everything to start using it ASAP, ignoring the transition.

 Hmm, no; I think we must come up with a technical solution for the
 transition itself, be it to disable all icon cache support in Gtk for
 the time of the transition.

 But obviously "ASAP" is post-etch here.

> It seems like #4 is going to happen by default if nothing continues to be
> done about this issue. Is #1 feasable? What about #3?

 The length of the transition and other priorities have pushed this to
 post-etch in my TODO lists.  Beside, the various options were not
 discussed enough.  The start of a release cycle is IMO the right moment
 to start such a transition in Debian.


 Interestingly, thinking about this again made me realize there might a
 flaw with the current implementation: wont the icon cache prevent dpkg
 from deleting a directory which had some icons?

 I think it might a good idea to base the implementation on a list of
 directories for which icon caches should be created (per package).

 e.g. /usr/share/gtk+2.0/icon-cache-dirs/somebinarypackage.dirs would
 list directories where an icon cache should be maintained and we could
 either:
 1) delete all icon cache files (e.g.: removal of gtk, disabling of the
    cache for debugging or backports)
 2) update incrementally the icon cache after the installation of a
    package
 3) update all icon caches (e.g.: recovery from a broken FS / from
    backup)
 4) move the icon cache files to a separate hierarchy

 Perhaps you have a better understanding of dpkg as I do: do you agree
 icon caches might prevent the removal of empty dirs?  This would be a
 strong point in favor of a separate icon cache hierarchy (which would
 require some patching of Gtk).


 The approach I would currently favor would be to:
 a) patch Gtk post-etch to support a new setting, ideally "authorized
    dirs for icon caches" and/or "unauthorized dirs for icon caches",
    less ideally "icon cache enabled/disabled"
 b) update the implementation of dh_iconcache (+ update-icon-cache?) if
    needed
 c) start the (hopefully painless but probably long) transition


 But please do criticize the above, this topic wasn't challenged enough
 until now IMO.

   Bye,
-- 
Loïc Minier <lool at dooz.org>