Axel Thimm wrote:
On Fri, Dec 22, 2006 at 06:49:46AM -0600, Rex Dieter wrote:
> Axel Thimm wrote:
>> On Thu, Dec 21, 2006 at 10:13:34AM -0600, Rex Dieter wrote:
>>> Looks like Core folks won't settle for anything in between status-quo
>>> and 100% fix (no in-between-compromising like using xdg-utils), so let's
>>> give it a shot.
>> What is the 100% fix?
> 100% fix is loosely defined as satisfying the motivations/criteria
> outlined in the latest version of the proposal.
Yes, but how would that work technically? Would an equivalent of
gtk-update-icon-cache be run on a directory upon first access to a
file within a folder with an aged index.theme? That would the only
sensible "100% fix" sound like.
Yeah, something like that. The idea with the most momentum (among Core
folks) involves some sort of filesystem-monitoring deamon of some sort
to auto-update cache as needed. My initially-proposed cron job which
works (now) and is infinitely simpler, has pretty much been rejected.
Frankly, I don't care about the details of solving that: *it is not
our(PC) problem* to address or solve.
> Note, however, that 100% fix is outside the scope of packaging
> guidelines. One thing that needs fixing wrt guidelines, however, is to
> not regenerate icon cache on every single package install, hence, why
> this newest version of the proposal drops the use of
> gtk-update-icon-cache in %post/%postun. On this, everyone from Core
> agrees (including Matthias, gtk maintainer).
And what about the vaccuum that this leaves behind? A non-updated gtk
cache mechanism that cannot share mmaped icons? I don't known how bad
that actually is, but why not wait with changing the guidelines until
any better mechanism is in place?
Sigh, problem being, we've now been waiting 14+ months for this
theoretical better mechanism. You're willing to wait indefinitely? Not
me. Further, I vehemently argue that problem is outside the scope of
packaging guidelines. Let's try to keep focus on what we (as packaging
committee) *can* solve, please.
-- Rex
-- Rex