Bug#407837: gtk icon cache transition problems

[Loïc Minier]

On Sun, Jan 21, 2007, Joey Hess wrote:
> >  This was depicted as defeating the purpose of the cache.  It might be
> >  an acceptable solution during the transition.
> Are cache misses really so common that this would render the caching
> useless? Why?

 While trying to dig the relevant discussions, I found the discussion
 with Gtk+ upstream:
    <http://bugzilla.gnome.org/show_bug.cgi?id=167941>
 (see how we discuss the very same options again ;)

 The discussion continued on the xdg list:
    <http://lists.freedesktop.org/archives/xdg/2005-October/thread.html#7392>

 I'm afraid I couldn't find the exact comment I mentionned; I'm almost
 certain it was from Gtk's upstream, either on a list or in the
 bugtracker or on IRC, but I couldn't find it.  (But as you can see, it
 was proposed.)  I even recall someone from upstream being actually open
 to accepting such a patch, but I think this changed later on.

> >  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.
> The flag could be anything, even a .dontcache file in individual
> directories.

 It's very different to implement it as a configuration of a postinst
 snippet (3-a) or as a runtime behavior of Gtk itself (3-b).  Yes, it
 could be a .dontcache, but if we change Gtk, it might be worth it to
 introduce a setting which can be overriden at various levels and does
 not add stat()s at runtime (Gtk already reads Gtk rc per-host,
 per-architecture, per-user).

> Obviously by "immediately", I mean post-etch, but we simply cannot wait
> forever for some ideal technical solution, the perfect becomes the enemy
> of the good at some point, and that point may have already arrived. Your
> example of not being able to install third-party packages built on an
> ubuntu system without breaking things is a good example.

 I understand, but it's not very easy to work on the Gtk packages right
 now as they are in the middle of plenty of transitions already:
 - move to multiarch (between 2.8 and 2.10)
 - support of ia32-libs (in progress in 2.8, will have to be ported to
   2.10)
 - module ABI change (between 2.8 and 2.10, introduces conflicts with
   all modules from unstable)
   The GNOME 2.16 stack needs Gtk 2.10, and it's not easy to work with
 only experimental for this.
   So, it's not like I am against implementing it, it's just not the
 perfect time and should be discussed a little first.

> I think that this is dealt with by the prerm+postrm code in #329460.

 Well, *doh*, I was tracking #369755 and didn't knew about #329460.  I
 think you can merge the two as they are about the same request for
 changes IMO.
   Indeed, it solves the directory removal problem.  What do you think
 of the other use cases?

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