FYI, updated iconcache proposal v0.5: * nixed xdg-utils. * Updated motivations/justifications, * gtk2 implementation suggestions/links,
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
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.
This time round, I'll try to put all relavent suggestions, comments, dialog on the wiki. Hopefully, that will help keep those not following the intimate details of the ml threads informed.
-- Rex
Rex Dieter wrote:
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
...
This time round, I'll try to put all relavent suggestions, comments, dialog on the wiki. Hopefully, that will help keep those not following the intimate details of the ml threads informed.
Heck, it is a *wiki* afterall, everyone with input is encouraged to add content there.
-- Rex
On Thu, 2006-12-21 at 10:13 -0600, Rex Dieter wrote:
FYI, updated iconcache proposal v0.5:
- nixed xdg-utils.
- Updated motivations/justifications,
- gtk2 implementation suggestions/links,
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
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.
Due to this and due to the fact the current practice is impractical and defective, I am in favor of scratching all coverage of handling icon caches in the GuideLines until somebody can provide a functional, portable and GUI-independent solution.
Ralf
Ralf Corsepius wrote:
On Thu, 2006-12-21 at 10:13 -0600, Rex Dieter wrote:
FYI, updated iconcache proposal v0.5:
- nixed xdg-utils.
- Updated motivations/justifications,
- gtk2 implementation suggestions/links,
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
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.
Due to this and due to the fact the current practice is impractical and defective, I am in favor of scratching all coverage of handling icon caches in the GuideLines until somebody can provide a functional, portable and GUI-independent solution.
As it turns out, the current proposal satisfies your criteria... it is just worded a little nicer. (:
-- Rex
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?
I'm just comapring this to ldconfig, which is a similar issue, right? What would the 100% fix be there? inotify on /lib,/usr/lib? What about scrollkeeper?
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.
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).
-- Rex
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.
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?
BTW
# time gtk-update-icon-cache; time ldconfig
real 0m0.003s user 0m0.001s sys 0m0.002s
real 0m0.274s user 0m0.130s sys 0m0.143s
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
On Friday 22 December 2006 08:37, Rex Dieter wrote:
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.
I'm not keen on creating rules to "force" the issue though. That is not a good "use" of our power. We have constraints to work within, those constraints being what the operating system can handle. Lets not make this a political thing. We're not going to go ban the use of ldconfig in %post until the rpm folks work out a way to do it in stages when needed, so why would we do it for icon cache too?
Jesse Keating wrote:
On Friday 22 December 2006 08:37, Rex Dieter wrote:
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.
I'm not keen on creating rules to "force" the issue though.
IMO, we're not trying to force anything here. We're trying to fix what is in our domain to fix. Most feedback I've received (even that from Matthias) agrees this is a *good thing*.
Lets not make this a political thing.
This is *so* not a political thing. I regret ever even treading on those troubled waters(1). I've resigned myself on trying to solve the *technical* problem only, at least that which is within our domain to do so.
We're not going to go ban the use of ldconfig in %post until the rpm folks work out a way to do it in stages when needed, so why would we do it for icon cache too?
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
How about we turn this around a bit, instead of focusing on the bad, how about something good that could come of this: installs/updates will go a heck of a lot faster, ~0.2-0.5 seconds per package! I wonder how faster a default Fedora install would be. (:
-- Rex
(1) Yes, I got a little pissy when my proposed cron-job solution was rejected out-of-hand, for some better, unimplimented, theoretical one. I'm over it, I've moved on, I feel better now. Really.
On Friday 22 December 2006 09:22, Rex Dieter wrote:
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
Ah! I missed this point. If the above statement is true, I'm all for it. I had thought we were going down the road of making a rule that would leave the cache unupdated period, and Some Other Process As Of Yet Unwritten would have to clean up behind us. If this happens already, and all the end user sees is a slight delay, I'm for it.
Jesse Keating wrote:
On Friday 22 December 2006 09:22, Rex Dieter wrote:
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
Ah! I missed this point. If the above statement is true, I'm all for it. I had thought we were going down the road of making a rule that would leave the cache unupdated period, and Some Other Process As Of Yet Unwritten would have to clean up behind us. If this happens already, and all the end user sees is a slight delay, I'm for it.
Yay! Christmas came early!
-- Rex
On Fri, 2006-12-22 at 09:26 -0500, Jesse Keating wrote:
On Friday 22 December 2006 09:22, Rex Dieter wrote:
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
Ah! I missed this point. If the above statement is true, I'm all for it. I had thought we were going down the road of making a rule that would leave the cache unupdated period, and Some Other Process As Of Yet Unwritten would have to clean up behind us. If this happens already, and all the end user sees is a slight delay, I'm for it.
Rex may need to correct me here but I believe with the current gtk package and removing the gtk-update-icon-cache calls in the %post scripts will create a situation where the cache is not updated consistently. Only when a package that has a gtk-update-icon-cache scriptlet is installed/updated will the cache be updated.
The difference Rex is speaking of is the level of necessity of ldconfig's cache vs the iconcache. If the iconcache is not up to date gtk is supposed to fall back to not using the cache. If ldconfig's cache is not updated, basic pieces of the system can go boom.
That said, if we want to change the guidelines, to not require the iconcache is in place I'd like to see something take care of updating the cache if it's out of date. So the choices I see are:
1) Leave the guidelines the way they are. The drawbacks have been stated several times with different ones being important to different people. 2) Use Rex's cron script. This leaves a stale cache around part of the time but has the benefit of being written now. 3) Write a file watching daemon that can refresh the cache when new files are installed. (This may either be a daemon specific to gtk or, as Havoc suggested in bugzilla, a generic daemon that can be configured to invoke a program when a filesystem event occurs.)
Matthias, in the bug report it seemed that you weren't opposed to leaving the scriptlets out of the packages and let the icon cache go stale. Is there a reason not to include the cron script as a temporary measure until a script to monitor for icon changes is written?
-Toshio
Toshio Kuratomi wrote:
Rex may need to correct me here but I believe with the current gtk package and removing the gtk-update-icon-cache calls in the %post scripts will create a situation where the cache is not updated consistently. Only when a package that has a gtk-update-icon-cache scriptlet is installed/updated will the cache be updated.
Correct. icon cache coherency is (still) the unsolved/unimplemented part of this issue.
FYI, I've updated the icon cache wiki so that this has it's own section, since it really is a separate issue, outside the scope of packaging guidelines.
-- Rex
On Fri, Dec 22, 2006 at 09:23:05AM -0800, Toshio Kuratomi wrote:
On Fri, 2006-12-22 at 09:26 -0500, Jesse Keating wrote:
On Friday 22 December 2006 09:22, Rex Dieter wrote:
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
Ah! I missed this point. If the above statement is true, I'm all for it. I had thought we were going down the road of making a rule that would leave the cache unupdated period, and Some Other Process As Of Yet Unwritten would have to clean up behind us. If this happens already, and all the end user sees is a slight delay, I'm for it.
Rex may need to correct me here but I believe with the current gtk package and removing the gtk-update-icon-cache calls in the %post scripts will create a situation where the cache is not updated consistently. Only when a package that has a gtk-update-icon-cache scriptlet is installed/updated will the cache be updated.
The difference Rex is speaking of is the level of necessity of ldconfig's cache vs the iconcache. If the iconcache is not up to date gtk is supposed to fall back to not using the cache. If ldconfig's cache is not updated, basic pieces of the system can go boom.
That said, if we want to change the guidelines, to not require the iconcache is in place I'd like to see something take care of updating the cache if it's out of date. So the choices I see are:
- Leave the guidelines the way they are. The drawbacks have been
stated several times with different ones being important to different people. 2) Use Rex's cron script. This leaves a stale cache around part of the time but has the benefit of being written now. 3) Write a file watching daemon that can refresh the cache when new files are installed. (This may either be a daemon specific to gtk or, as Havoc suggested in bugzilla, a generic daemon that can be configured to invoke a program when a filesystem event occurs.)
or
4) have gtk do the cache maintenance it on the fly, e.g. when an icon is accessed gtk checks for index.theme's timestamp in the folder the icon is in and does the equivalent to gtk-update-icon-cache in the background?
I'd prefer that over 3) because if you have a folder inotify a daemon you'd be running the updating again several times per larger rpm transaction. Unless that daemon would have a wait timeout on inotifies to collect several triggers, but then it sounds easier to do 4)
Matthias, in the bug report it seemed that you weren't opposed to leaving the scriptlets out of the packages and let the icon cache go stale. Is there a reason not to include the cron script as a temporary measure until a script to monitor for icon changes is written?
I'd also prefer a simpler packages + cron script until the "100% fix" :)
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> I'd prefer that over 3) because if you have a folder inotify a AT> daemon you'd be running the updating again several times per AT> larger rpm transaction. Unless that daemon would have a wait AT> timeout on inotifies to collect several triggers, but then it AT> sounds easier to do 4)
Besides, how do you then update the cache during, say, the initial install, or if I install some packages in single-user mode? Hopefully the installer won't have to start a pile of daemons just to get a proper system.
I have to wonder, are the people who advocate keeping a daemon running forever to keep things in sync over a one-line crontab the same ones who oppose xdg-utils because it's a shell script of moderate length? Because if so, there seems to be a significant disconnect there and I'm having trouble figuring out what the rules are.
- J<
On Fri, Dec 22, 2006 at 01:33:14PM -0600, Jason L Tibbitts III wrote:
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> I'd prefer that over 3) because if you have a folder inotify a AT> daemon you'd be running the updating again several times per AT> larger rpm transaction. Unless that daemon would have a wait AT> timeout on inotifies to collect several triggers, but then it AT> sounds easier to do 4)
Besides, how do you then update the cache during, say, the initial install, or if I install some packages in single-user mode? Hopefully the installer won't have to start a pile of daemons just to get a proper system.
I have to wonder, are the people who advocate keeping a daemon running forever to keep things in sync over a one-line crontab the same ones who oppose xdg-utils because it's a shell script of moderate length? Because if so, there seems to be a significant disconnect there and I'm having trouble figuring out what the rules are.
I wasn't thinking of forking daemons for the on-the-fly cache updating, more a side effect of using gtk libs, e.g. a model like python creating pyc on the fly, tex creating fonts etc.
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> I wasn't thinking of forking daemons for the on-the-fly cache AT> updating, more a side effect of using gtk libs, e.g. a model like AT> python creating pyc on the fly, tex creating fonts etc.
The python setup requires that the specific scripts run as root; the TeX stuff requires rather tricky things like world-writable directories or setgid bits. Neither is close to ideal.
In any case, it seems as if one proposed solution does indeed require a daemon sitting around watching for changes to the icon directories and regenerating the cache on the fly. That's what I was commenting on.
- J<
On Fri, Dec 22, 2006 at 02:46:10PM -0600, Jason L Tibbitts III wrote:
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> I wasn't thinking of forking daemons for the on-the-fly cache AT> updating, more a side effect of using gtk libs, e.g. a model like AT> python creating pyc on the fly, tex creating fonts etc.
The python setup requires that the specific scripts run as root; the TeX stuff requires rather tricky things like world-writable directories or setgid bits. Neither is close to ideal.
Those were just examples, noone suggests copying the implementations ;) There is anyway the question of having generated files under /usr, e.g. a better implementation of a cache will move the generated bit to under /var for stateless/livecd/ro-usr purposes.
In any case, it seems as if one proposed solution does indeed require a daemon sitting around watching for changes to the icon directories and regenerating the cache on the fly. That's what I was commenting on.
Well, we've become rather off-topic anyway, we're not gtk developers, and they probably already know what the solution will look like.
"AT" == Axel Thimm Axel.Thimm@ATrpms.net writes:
AT> Those were just examples, noone suggests copying the AT> implementations ;) There is anyway the question of having AT> generated files under /usr, e.g. a better implementation of a AT> cache will move the generated bit to under /var for AT> stateless/livecd/ro-usr purposes.
Wow, does it really store the cache under /usr? I didn't realize that. If people are really looking into the caching issue then they should look at fixing that as well.
- J<
On Fri, Dec 22, 2006 at 02:26:31PM +0100, Axel Thimm wrote:
# time gtk-update-icon-cache; time ldconfig
real 0m0.003s user 0m0.001s sys 0m0.002s
real 0m0.274s user 0m0.130s sys 0m0.143s
On Fri, Dec 22, 2006 at 08:22:13AM -0600, Rex Dieter wrote:
How about we turn this around a bit, instead of focusing on the bad, how about something good that could come of this: installs/updates will go a heck of a lot faster, ~0.2-0.5 seconds per package! I wonder how faster a default Fedora install would be. (:
Not a real winner on my 3 year old lappy. I'd need 300 gtk packages with redundant gtk-update-icon-cache to notice a second ;)
On Friday 22 December 2006 09:32, Axel Thimm wrote:
Not a real winner on my 3 year old lappy. I'd need 300 gtk packages with redundant gtk-update-icon-cache to notice a second
We should get seth to run this on the olpc, I bet there is a win there (:
Jesse Keating wrote:
On Friday 22 December 2006 09:32, Axel Thimm wrote:
Not a real winner on my 3 year old lappy. I'd need 300 gtk packages with redundant gtk-update-icon-cache to notice a second
We should get seth to run this on the olpc, I bet there is a win there (:
I'd bet $$ a big win.
-- Rex
Rex Dieter wrote:
Axel Thimm wrote:
On Fri, Dec 22, 2006 at 02:26:31PM +0100, Axel Thimm wrote:
# time gtk-update-icon-cache; time ldconfig
gtk-update-icon-cache is pretty much a no-op, if cache is fresh.
Try this instead: touch /usr/share/icons/hicolor time gtk-update-icon-cache
OK, how about a test that actually works: (: touch /usr/share/icons/hicolor time gtk-update-icon-cache /usr/share/icons/hicolor
-- Rex
Rex Dieter wrote:
Rex Dieter wrote:
Axel Thimm wrote:
On Fri, Dec 22, 2006 at 02:26:31PM +0100, Axel Thimm wrote:
# time gtk-update-icon-cache; time ldconfig
gtk-update-icon-cache is pretty much a no-op, if cache is fresh.
OK, how about a test that actually works: (: touch /usr/share/icons/hicolor time gtk-update-icon-cache /usr/share/icons/hicolor
Or even better, (for completeness): time gtk-update-icon-cache --force /usr/share/icons/hicolor
-- Rex
Rex Dieter wrote:
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
Stale icon cache has been known to break apps, though. nm-applet is one of them.
Christopher Aillon wrote:
Rex Dieter wrote:
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
Stale icon cache has been known to break apps, though. nm-applet is one of them.
That's either not true, or simply a bug somewhere. Matthias' has stated gtk2's implementation will(should!) fallback to using brute-force search when icon cache is not fresh.
-- Rex
Rex Dieter wrote:
Christopher Aillon wrote:
Rex Dieter wrote:
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
Stale icon cache has been known to break apps, though. nm-applet is one of them.
That's either not true, or simply a bug somewhere. Matthias' has stated gtk2's implementation will(should!) fallback to using brute-force search when icon cache is not fresh.
I'm not denying it is a bug somewhere that I'm trying to track down. What I'm saying is that there is the potential for breaking things due to whatever reasons. Saying that a stale cache does not cause things to break is a little misleading until the bugs are fixed.
On Thu, 28 Dec 2006 10:27:53 -0500, Christopher Aillon wrote:
Rex Dieter wrote:
Christopher Aillon wrote:
Rex Dieter wrote:
imo, ldconfig example isn't a good one, but I get your point. Difference being here, messing with ldconfig can horribly break things. A stale iconcache doesn't break anything, at worst only affects app startup time (a little).
Stale icon cache has been known to break apps, though. nm-applet is one of them.
That's either not true, or simply a bug somewhere. Matthias' has stated gtk2's implementation will(should!) fallback to using brute-force search when icon cache is not fresh.
I'm not denying it is a bug somewhere that I'm trying to track down. What I'm saying is that there is the potential for breaking things due to whatever reasons. Saying that a stale cache does not cause things to break is a little misleading until the bugs are fixed.
It is a bug somewhere and the reason why gtk-update-icon-cache is executed in post-install scriptlets. It's the only way freshly installed icons show up in the GNOME desktop menu.
Michael Schwendt wrote:
It is a bug somewhere and the reason why gtk-update-icon-cache is executed in post-install scriptlets. It's the only way freshly installed icons show up in the GNOME desktop menu.
Running gtk-update-icon-cache is *not* the *only* way to see new icons. touch'ing the top-level icon dir is (should be!) sufficient for that.
-- Rex
On Sun, 31 Dec 2006 21:41:04 -0600, Rex Dieter wrote:
It is a bug somewhere and the reason why gtk-update-icon-cache is executed in post-install scriptlets. It's the only way freshly installed icons show up in the GNOME desktop menu.
Running gtk-update-icon-cache is *not* the *only* way to see new icons. touch'ing the top-level icon dir is (should be!) sufficient for that.
Yes, but it's a _manual operation_, because the last-modified time-stamp of that directory is not updated when a sub-directory is changed. And gtk-update-icon-cache doesn't do anything unless the top-level directory has changed (or is touched!). Hence running this stuff manually cannot be avoided so far.
Also, the GNOME menu seems somewhat slow in noticing the fresh time-stamp. Probably due to some 2nd level of caching.
Michael Schwendt wrote:
On Sun, 31 Dec 2006 21:41:04 -0600, Rex Dieter wrote:
It is a bug somewhere and the reason why gtk-update-icon-cache is executed in post-install scriptlets. It's the only way freshly installed icons show up in the GNOME desktop menu.
Running gtk-update-icon-cache is *not* the *only* way to see new icons. touch'ing the top-level icon dir is (should be!) sufficient for that.
Yes, but it's a _manual operation_, because the last-modified time-stamp of that directory is not updated when a sub-directory is changed. And gtk-update-icon-cache doesn't do anything unless the top-level directory has changed (or is touched!). Hence running this stuff manually cannot be avoided so far.
No one has ever suggested that 'touch' could be avoided. I don't think it can, the icon spec requires it. My point was that only 'touch' is required for proper function. Contrary to what it appeared (to me anyway) you were asserting, gtk-update-icon-cache is not required for proper function, being nothing more than an optimization (akin to prelink).
-- Rex
On Mon, 01 Jan 2007 08:14:35 -0600, Rex Dieter wrote:
Michael Schwendt wrote:
On Sun, 31 Dec 2006 21:41:04 -0600, Rex Dieter wrote:
It is a bug somewhere and the reason why gtk-update-icon-cache is executed in post-install scriptlets. It's the only way freshly installed icons show up in the GNOME desktop menu.
Running gtk-update-icon-cache is *not* the *only* way to see new icons. touch'ing the top-level icon dir is (should be!) sufficient for that.
Yes, but it's a _manual operation_, because the last-modified time-stamp of that directory is not updated when a sub-directory is changed. And gtk-update-icon-cache doesn't do anything unless the top-level directory has changed (or is touched!). Hence running this stuff manually cannot be avoided so far.
No one has ever suggested that 'touch' could be avoided. I don't think it can, the icon spec requires it. My point was that only 'touch' is required for proper function. Contrary to what it appeared (to me anyway) you were asserting, gtk-update-icon-cache is not required for proper function, being nothing more than an optimization (akin to prelink).
I've put it inaccurately, yes, and refer to the scriptlet in the Wiki. Let me rephrase: Only the non-trivial combination of touch plus gtk-update-icon-cache (or only gtk-update-icon-cache --force) updates the cache. And if a post-install scriptlet must be added anyway to touch a directory, running a second program in the same shell script is an obvious thing to do.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Christopher Aillon -
Jason L Tibbitts III -
Jesse Keating -
Michael Schwendt -
Ralf Corsepius -
Rex Dieter -
Toshio Kuratomi