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 <[EMAIL PROTECTED]>
