I posted this proposal awhile back: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
Don't remember seeing much (any?) feedback, so everyone must agree with it. (:
I'd like to get this discussed and ratified by the committee.
-- Rex
On Mon, 2006-12-04 at 15:36 -0600, Rex Dieter wrote:
I posted this proposal awhile back: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
Don't remember seeing much (any?) feedback, so everyone must agree with it. (:
I'd like to get this discussed and ratified by the committee.
I wrote something but it was much after the fact and in a totally different thread. Here's my comments: ''' I'm sorry I missed the initial announcement of this. I think your revisions make sense after xdg-utils go into Core and the requirement tree for gtk2 is in place (hicolor-icon-theme should work fine for this). Changing the guidelines before that would break things that currently work. (Or we could place a hard Require:s on xdg-utils until it was fixed.)
Is there an RFE open to get xdg-utils into Core and make the necessary changes? If the relevant maintainers think it's a good change we can mention that the suggested scriptlet is changing in FCX. '''[1]_ [1]_ https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00011.ht...
Toshio Kuratomi wrote:
On Mon, 2006-12-04 at 15:36 -0600, Rex Dieter wrote:
I posted this proposal awhile back: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
I'm sorry I missed the initial announcement of this. I think your revisions make sense after xdg-utils go into Core and the requirement tree for gtk2 is in place (hicolor-icon-theme should work fine for this). Changing the guidelines before that would break things that currently work. (Or we could place a hard Require:s on xdg-utils until it was fixed.)
In any case, nothing would break. At worst, gtk apps would suffer a performance penalty, at least until gtk2 is fixed: http://bugzilla.redhat.com/170335 (a personal packaging pet-peave).
Is there an RFE open to get xdg-utils into Core and make the necessary changes?
IMO, it's a no-brainer, but likely not relavant, due to the proposed/likely merge of Core/Extras for FC-7 (see http://fedoraproject.org/wiki/FedoraSummit/OpeningCore)
-- Rex
On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote:
Toshio Kuratomi wrote:
On Mon, 2006-12-04 at 15:36 -0600, Rex Dieter wrote:
I posted this proposal awhile back: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
I'm sorry I missed the initial announcement of this. I think your revisions make sense after xdg-utils go into Core and the requirement tree for gtk2 is in place (hicolor-icon-theme should work fine for this). Changing the guidelines before that would break things that currently work. (Or we could place a hard Require:s on xdg-utils until it was fixed.)
In any case, nothing would break. At worst, gtk apps would suffer a performance penalty, at least until gtk2 is fixed: http://bugzilla.redhat.com/170335 (a personal packaging pet-peave).
Yes. Which is a regression.
I agree that 170335 should be fixed, though.
There's three issues with gtk-update-icon-path in that bug: 1) It would be great if we didn't have to call gtk-update-icon-cache in every rpm that provides icons 2) gtk-update-icon-cache is inefficient as it may get called multiple times when several packages that install icons are installed in the same transaction (and it really only needs to be run once). 3) gtk2 needs to run gtk-update-icon-cache (or the xdg equivalent) in its %post so all the packages which defer updating the cache until gtk2 is installed have the cache updated when that happens.
Is there an RFE open to get xdg-utils into Core and make the necessary changes?
IMO, it's a no-brainer, but likely not relavant, due to the proposed/likely merge of Core/Extras for FC-7 (see http://fedoraproject.org/wiki/FedoraSummit/OpeningCore)
It's still relevant since we're going to spin some sort of distro (rather than say, "hey kids, here's a bunch of packages!") What needs to happen is that gtk2 needs to Require: xdg-utils (and use it in its % post ;-) In FC-6 this would require xdg-utils to move to Core. In Fedora 7, hopefully the "move to Core" part will be superfluous. But xdg-utils will need to be part of whatever platform gtk2 belongs to.
-Toshio
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote:
Toshio Kuratomi wrote:
On Mon, 2006-12-04 at 15:36 -0600, Rex Dieter wrote:
I posted this proposal awhile back: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
I'm sorry I missed the initial announcement of this. I think your revisions make sense after xdg-utils go into Core and the requirement tree for gtk2 is in place (hicolor-icon-theme should work fine for this). Changing the guidelines before that would break things that currently work. (Or we could place a hard Require:s on xdg-utils until it was fixed.)
In any case, nothing would break. At worst, gtk apps would suffer a performance penalty, at least until gtk2 is fixed: http://bugzilla.redhat.com/170335 (a personal packaging pet-peave).
Yes. Which is a regression. I agree that 170335 should be fixed, though.
Bingo. Bugs should be addressed in their proper domain, and I would argue strongly that the proper domain in the gtk2 (bug #170335) case is *gtk2*, not Packaging/Guidelines.
-- Rex
On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote:
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote:
In any case, nothing would break. At worst, gtk apps would suffer a performance penalty, at least until gtk2 is fixed: http://bugzilla.redhat.com/170335 (a personal packaging pet-peave).
Yes. Which is a regression. I agree that 170335 should be fixed, though.
Bingo. Bugs should be addressed in their proper domain, and I would argue strongly that the proper domain in the gtk2 (bug #170335) case is *gtk2*, not Packaging/Guidelines.
We have had and continue to have many pieces of guidelines which are held up by or written to account for bugs in support packages (rpm, scriptlets in Core packages, etc).
I would argue that we want our packages to provide a bug free experience for our users. We can write what should happen in the Guidelines but if there's a problem due to bugs and there's a workaround, we should also endorse the workaround until the bug is resolved.
In this case, I'd be okay with the changes to iconcache with 1) the addition of Requires(post): xdg-utils 2) note that the Requires(post) can go away after bug #NNNN is resolved where that bug asks for hicolor-icon-theme (gtk2 requires h-i-t) to do this:
''' Requires(post): xdg-utils [...] %post touch --no-create /usr/share/icons/hicolor %{_bindir}/xdg-icon-resource forceupdate --theme hicolor '''
-Toshio
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote:
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote:
In any case, nothing would break. At worst, gtk apps would suffer a performance penalty, at least until gtk2 is fixed: http://bugzilla.redhat.com/170335 (a personal packaging pet-peave).
Yes. Which is a regression. I agree that 170335 should be fixed, though.
Bingo. Bugs should be addressed in their proper domain, and I would argue strongly that the proper domain in the gtk2 (bug #170335) case is *gtk2*, not Packaging/Guidelines.
We have had and continue to have many pieces of guidelines which are held up by or written to account for bugs in support packages (rpm, scriptlets in Core packages, etc).
...
In this case, I'd be okay with the changes to iconcache with
or I would have no problem with 0) hold publication of the new guideline pending one of: a) wait (indefinitely) until gtk2 bug is fixed b) give gtk2 maintainer reasonable time to fix (2-4 weeks?), then just do it. c) (I'm almost serious): make gtk2-fixbug170335-hack package, and use Requires(post,postun): gtk2-fixbug170335-hack (:
If possible, I'd rather avoid complicating the guidelines (and packagers) lives with the, imo, unecessary extra baggage entailed with 1 or 2, by introducing a new Requires(post,postun): xdg-utils But, if the rest of the comittee is agreeable to the idea, I'll play along.
- the addition of Requires(post): xdg-utils
- note that the Requires(post) can go away after bug #NNNN is resolved
where that bug asks for hicolor-icon-theme (gtk2 requires h-i-t) to do this:
''' Requires(post): xdg-utils [...] %post touch --no-create /usr/share/icons/hicolor %{_bindir}/xdg-icon-resource forceupdate --theme hicolor '''
On Tue, 2006-12-05 at 15:27 -0600, Rex Dieter wrote:
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote:
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 10:06 -0600, Rex Dieter wrote:
In any case, nothing would break. At worst, gtk apps would suffer a performance penalty, at least until gtk2 is fixed: http://bugzilla.redhat.com/170335 (a personal packaging pet-peave).
Yes. Which is a regression. I agree that 170335 should be fixed, though.
Bingo. Bugs should be addressed in their proper domain, and I would argue strongly that the proper domain in the gtk2 (bug #170335) case is *gtk2*, not Packaging/Guidelines.
We have had and continue to have many pieces of guidelines which are held up by or written to account for bugs in support packages (rpm, scriptlets in Core packages, etc).
...
In this case, I'd be okay with the changes to iconcache with
or I would have no problem with 0) hold publication of the new guideline pending one of: a) wait (indefinitely) until gtk2 bug is fixed b) give gtk2 maintainer reasonable time to fix (2-4 weeks?), then just do it. c) (I'm almost serious): make gtk2-fixbug170335-hack package, and use Requires(post,postun): gtk2-fixbug170335-hack (:
I could live with holding the guidelines pending updates to the core packages as well. I'd add d) hicolor-iconcache utilitizes xdg-utils.
If possible, I'd rather avoid complicating the guidelines (and packagers) lives with the, imo, unecessary extra baggage entailed with 1 or 2, by introducing a new Requires(post,postun): xdg-utils But, if the rest of the comittee is agreeable to the idea, I'll play along.
True but there's a good possibility the changes won't be implemented for all versions of FC anyhow. That means that we'll have to carry separate instructions for FCX and FCY no matter what.
-Toshio
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote:
In this case, I'd be okay with the changes to iconcache with
- the addition of Requires(post): xdg-utils
I forgot to mention, that this approach must be special-case, to only be for Extras packages, since xdg-utils isn't in Core (yet).
My original proposal applies equally well to all Core/Extras packages, for any FC release.
-- Rex
On Tue, 2006-12-05 at 22:51 -0600, Rex Dieter wrote:
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote:
In this case, I'd be okay with the changes to iconcache with
- the addition of Requires(post): xdg-utils
I forgot to mention, that this approach must be special-case, to only be for Extras packages, since xdg-utils isn't in Core (yet).
My original proposal applies equally well to all Core/Extras packages, for any FC release.
My feeling is it's broken on Core since xdg-utils isn't present there. My proposal forces the issue. If you have to Requires(post): xdg-utils, you have to have it in Core (or the Core equivalent).
-Toshio
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 22:51 -0600, Rex Dieter wrote:
Toshio Kuratomi wrote:
On Tue, 2006-12-05 at 14:05 -0600, Rex Dieter wrote: In this case, I'd be okay with the changes to iconcache with
- the addition of Requires(post): xdg-utils
I forgot to mention, that this approach must be special-case, to only be for Extras packages, since xdg-utils isn't in Core (yet).
My original proposal applies equally well to all Core/Extras packages, for any FC release.
My feeling is it's broken on Core since xdg-utils isn't present there.
If by "broken", you *really* mean: "regressing" causing gtk2 app performance degradation until gtk2 is fixed, then yes.
My proposal forces the issue. If you have to Requires(post): xdg-utils, you have to have it in Core (or the Core equivalent).
Force what? It is impossible to get xdg-utils into pre FC-7 Core. That's why I mentioned it would have to be an (imo overly complicated) special-case for FC-7+ only.
-- Rex
rdieter@math.unl.edu (Rex Dieter) writes:
I posted this proposal awhile back: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
Don't remember seeing much (any?) feedback, so everyone must agree with it. (:
I'd like to get this discussed and ratified by the committee.
Why the 'touch' stuff? At least 'gtk-update-icon-cache' knows a '--force' option which should have the wanted effect but adds less clutter.
Enrico
Enrico Scholz wrote:
rdieter@math.unl.edu (Rex Dieter) writes:
I posted this proposal awhile back: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
Don't remember seeing much (any?) feedback, so everyone must agree with it. (:
I'd like to get this discussed and ratified by the committee.
Why the 'touch' stuff?
The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated.
At least 'gtk-update-icon-cache' knows a '--force' option which should have the wanted effect but adds less clutter.
Dropping the 'touch' and using *only* gtk-update-icon-cache --force (or even xdg-icon-resource forceupdate) would require the tool to be present at install-time, and necessitate Requires(post,postun): foo which, imo, should be avoided, if at all possible.
Further, one of the major motivations for the proposal was to avoid the use of of any toolkit-specific tool (ie, gtk-update-icon-cache). I (and many others) have long argued that it is inappropriate to shoe-horn a toolkit-specific gtk-update-icon-cache into *every* package installing icons. I would like to hope that updating the packaging guidelines thusly would "motivate" the gtk2 maintainer to do something about the long-standing: http://bugzilla.redhat.com/170335
-- Rex
rdieter@math.unl.edu (Rex Dieter) writes:
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
... Why the 'touch' stuff?
The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated.
What is a 'fdo spec'?
At least 'gtk-update-icon-cache' knows a '--force' option which should have the wanted effect but adds less clutter.
Dropping the 'touch' and using *only* gtk-update-icon-cache --force (or even xdg-icon-resource forceupdate) would require the tool to be present at install-time, and necessitate Requires(post,postun): foo which, imo, should be avoided, if at all possible.
I do not see how
| %{_bindir}/gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || :
vs.
| touch --no-create %{_datadir}/icons/hicolor || : | %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
would led to your conclusion.
Enrico
Enrico Scholz wrote:
rdieter@math.unl.edu (Rex Dieter) writes:
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
... Why the 'touch' stuff?
The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated.
What is a 'fdo spec'?
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html...
At least 'gtk-update-icon-cache' knows a '--force' option which should have the wanted effect but adds less clutter.
Dropping the 'touch' and using *only* gtk-update-icon-cache --force (or even xdg-icon-resource forceupdate) would require the tool to be present at install-time, and necessitate Requires(post,postun): foo which, imo, should be avoided, if at all possible.
I do not see how
| gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || : vs. | touch --no-create %{_datadir}/icons/hicolor || : | %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : would led to your conclusion.
Consider the case that gtk2 (and gtk-update-icon-cache) is not present at install-time (since we currently don't Requires(post,postun): gtk2), then the icondir timestamp will fail to be updated.
-- Rex
rdieter@math.unl.edu (Rex Dieter) writes:
Why the 'touch' stuff?
The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated.
What is a 'fdo spec'?
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html...
Oh, I see. The 'touch' makes a differences when user installed a 3rd party application with a 3rd party toolkit which is following freedesktop.org iconcache-recommendations.
| gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || : vs. | touch --no-create %{_datadir}/icons/hicolor || : | %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : would led to your conclusion.
Consider the case that gtk2 (and gtk-update-icon-cache) is not present at install-time (since we currently don't Requires(post,postun): gtk2),
Please don't write 'Requires(post,postun):'; dunno whether you meant it symbolically only. But it's wrong and sickly.
then the icondir timestamp will fail to be updated.
This would not make a difference: in both cases ('touch' and '--force') the iconcache will be updated in the same manner during the installation of 'gtk-update-icon-cache'.
Currently (with FC5 gtk2), icon-cache won't be updated because gtk2's scriptlets do not call 'gtk-update-icon-cache'.
Enrico
Enrico Scholz wrote:
rdieter@math.unl.edu (Rex Dieter) writes:
Why the 'touch' stuff?
The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated.
What is a 'fdo spec'?
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html...
Oh, I see. The 'touch' makes a differences when user installed a 3rd party application with a 3rd party toolkit which is following freedesktop.org iconcache-recommendations.
Take 3rd party of it. This includes *all* apps using *any* toolkit.
| gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || : vs. | touch --no-create %{_datadir}/icons/hicolor || : | %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : would led to your conclusion.
Consider the case that gtk2 (and gtk-update-icon-cache) is not present at install-time (since we currently don't Requires(post,postun): gtk2),
Please don't write 'Requires(post,postun):'; dunno whether you meant it symbolically only. But it's wrong and sickly.
It's simply shorter than writing (the more proper and working): Requires(post): gtk2 Requires(postun): gtk2
then the icondir timestamp will fail to be updated.
This would not make a difference: in both cases ('touch' and '--force') the iconcache will be updated in the same manner during the installation of 'gtk-update-icon-cache'.
OK, I'll say it one more time: Lacking Requires(post): gtk2 Requires(postun): gtk2 *gtk2 may not be present at install-time*. As such, gtk-update-icon-cache present in scriplets may not get run, thus, the icondir timestamp may not get updated.
Am I missing something?
Currently (with FC5 gtk2), icon-cache won't be updated because gtk2's scriptlets do not call 'gtk-update-icon-cache'.
Neither does *any* gtk2 release, for that matter. That's related to the gtk2 bug, that our currently scriplets are covering up. I'm concerned that the bug will never get fixed or get the attention it deserves if the bandaid is never (threatened to be) removed.
-- Rex
Rex Dieter wrote:
Enrico Scholz wrote:
rdieter@math.unl.edu (Rex Dieter) writes:
Why the 'touch' stuff?
The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated.
What is a 'fdo spec'?
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html...
Oh, I see. The 'touch' makes a differences when user installed a 3rd party application with a 3rd party toolkit which is following freedesktop.org iconcache-recommendations.
Take 3rd party of it. This includes *all* apps using *any* toolkit.
Sorry, meant to say: take 3rd party out of it.
-- Rex
rdieter@math.unl.edu (Rex Dieter) writes:
Why the 'touch' stuff?
The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated.
What is a 'fdo spec'?
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html...
Oh, I see. The 'touch' makes a differences when user installed a 3rd party application with a 3rd party toolkit which is following freedesktop.org iconcache-recommendations.
Take 3rd party of it. This includes *all* apps using *any* toolkit.
Does gtk1, QT or wxWindows implement the freedesktop icon caching?
then the icondir timestamp will fail to be updated.
This would not make a difference: in both cases ('touch' and '--force') the iconcache will be updated in the same manner during the installation of 'gtk-update-icon-cache'.
OK, I'll say it one more time: Lacking Requires(post): gtk2 Requires(postun): gtk2 *gtk2 may not be present at install-time*. As such, gtk-update-icon-cache present in scriplets may not get run, thus, the icondir timestamp may not get updated.
Am I missing something?
yes; the timestamp itself is important for gtk (and other toolkits following the freedesktop recommendations) only. Not touching the timestamp would cause only currently running 3rd party apps (using such a toolkit) not to recognize the new icons.
Enrico
Enrico Scholz wrote:
rdieter@math.unl.edu (Rex Dieter) writes:
> Why the 'touch' stuff? The fdo spec mandates the timestamp of the installed-to icon dir *must* be updated.
What is a 'fdo spec'?
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html...
Oh, I see. The 'touch' makes a differences when user installed a 3rd party application with a 3rd party toolkit which is following freedesktop.org iconcache-recommendations.
Take 3rd party of it. This includes *all* apps using *any* toolkit.
Does gtk1, QT or wxWindows implement the freedesktop icon caching?
kde does, the others, dunno, but imo, doesn't matter. Fact is, any toolkit *could* implement caching, and the standard mandates that in order for any caching implementation to work, the timestamp must be updated.
I hope you're not suggesting that it be ok to purposely not follow the standard.
then the icondir timestamp will fail to be updated.
This would not make a difference: in both cases ('touch' and '--force') the iconcache will be updated in the same manner during the installation of 'gtk-update-icon-cache'.
OK, I'll say it one more time: Lacking Requires(post): gtk2 Requires(postun): gtk2 *gtk2 may not be present at install-time*. As such, gtk-update-icon-cache present in scriplets may not get run, thus, the icondir timestamp may not get updated.
Am I missing something?
yes; the timestamp itself is important for gtk (and other toolkits following the freedesktop recommendations) only.
Of course, that's a given.
Not touching the timestamp would cause only currently running 3rd party apps (using such a toolkit) not to recognize the new icons.
Wrong, it would (ok, could, depending on imlementation) cause any app (currently running or not), using any toolkit (that supports the fdo) spec to not recognize the new icons.
-- Rex
Rex Dieter wrote:
Enrico Scholz wrote:
Not touching the timestamp would cause only currently running 3rd party apps (using such a toolkit) not to recognize the new icons.
Wrong, it would (ok, could, depending on imlementation) cause any app (currently running or not), using any toolkit (that supports the fdo) spec to not recognize the new icons.
After re-reading what you said, my only objections were your use of 'only currently running' and '3rd party'. Take those out, and we're pretty much on the same page.
-- Rex
packaging@lists.fedoraproject.org
-
Enrico Scholz -
Rex Dieter -
Toshio Kuratomi