Loïc Minier wrote: > > 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.
Are cache misses really so common that this would render the caching useless? Why? > > 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. The flag could be anything, even a .dontcache file in individual directories. > > 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. 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. (Granted, it's also an example of why I've constantly railed against Ubuntu for forking their version of debhelper. If they had paid heed to that or sent me a debhelper patch to review before deploying it, this could have possibly been avoided.) > 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 that this is dealt with by the prerm+postrm code in #329460. -- see shy jo
signature.asc
Description: Digital signature
