Suggested ScriptletSnippets (icon cache) changes
 

Ville Skyttä <ville.skytta@iki.fi> writes:

> So the scriptlets would become:
>
> %post
> if [ $1 -eq 1 ] ; then
> touch --no-create %{_datadir}/icons/hicolor &>/dev/null
> gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
> fi
>
> %postun
> touch --no-create %{_datadir}/icons/hicolor &>/dev/null
> gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :

Why not

| %post
| touch --no-create %{_datadir}/icons/hicolor &>/dev/null
|
| %postun
| touch --no-create %{_datadir}/icons/hicolor &>/dev/null
|
| %posttrans
| gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :

? All relevant Fedora releases should understand %posttrans and this
speeds up things significantly.



Enrico

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Suggested ScriptletSnippets (icon cache) changes
 

On Wed, Jan 28, 2009 at 01:36:36 +0200,
Ville Skyttä <ville.skytta@iki.fi> wrote:
>
> 2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is not
> available when the package is removed, I find it more than likely that GTK+
> or KDE are not there to benefit from icon cache updates any longer
> either. /usr/share may also be mounted read only with %_netsharedpath.

The right way to do things is to make sure touch is available by
having an approiate script dependency on the package that provides touch.
Something like:
Requires(pre): coreutils

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Suggested ScriptletSnippets (icon cache) changes
 

On Wednesday 28 January 2009, Bruno Wolff III wrote:
> On Wed, Jan 28, 2009 at 01:36:36 +0200,
>
> Ville Skyttä <ville.skytta@iki.fi> wrote:
> > 2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is
> > not available when the package is removed, I find it more than likely
> > that GTK+ or KDE are not there to benefit from icon cache updates any
> > longer either. /usr/share may also be mounted read only with
> > %_netsharedpath.
>
> The right way to do things is to make sure touch is available by
> having an approiate script dependency on the package that provides touch.
> Something like:
> Requires(pre): coreutils

The point of the suggestion I posted is to avoid *unnecessary* dependencies
like this one as well as unnecessary calls to touch and
gtk-update-icon-cache. The part of my original message you quoted above
explains why I think it doesn't matter if touch is available at %postun time
or not (my assumption is that coreutils can't be removed while gtk2 or
kdelibs is installed). If I'm correct and it doesn't
matter, "Requires(postun): coreutils" is just unnecessary bloat in repodata,
rpmdb and spec files.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Suggested ScriptletSnippets (icon cache) changes
 

Bill Nottingham <notting@redhat.com> writes:

>> | %postun
>> | touch --no-create %{_datadir}/icons/hicolor &>/dev/null
>> |
>> | %posttrans
>> | gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
>
> As posttrans isn't collated into a single run, it just moves the total
> of calls from point A to point B,

no; gtk-update-icon-cache is cheap when icons/hicolor is up-to-date.
Hence, only the first %posttrans will update the icon cache. Subsequent
ones will be noops effectively.

With old method, there is a 'touch icons/hicolor' which invalidates
cache and makes every operation expensive.



Enrico

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Suggested ScriptletSnippets (icon cache) changes
 

Ville Skyttä wrote:
> Hello,
>
> So I gather as the result of this discussion would be:
>
> ----
> %post
> touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
>
> %postun
> if [ $1 -eq 0 ] ; then
> touch --no-create %{_datadir}/icons/hicolor &>/dev/null
> gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
> fi
>
> %posttrans
> gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
> ----
>
> Initial install and upgrades are handled by %post and %posttrans, final erase
> by %postun. Anything more to tweak? If not, is this discussion (see also 1)
> in my initial mail [0]) and summary enough for the FPC so you can look into
> it in a near future meeting?
>

https://fedoraproject.org/wiki/PackagingDrafts/Icon_Cache

Does that look good?

Couple questions, in the %postun, there's no || : for the touch. Is
that intentional? (If not, please change it for me :-)

If %posttrans should prove controversial (I don't see a problem but if
it is) is including the gtk-update-icon-cache call in %post in its
modified state acceptable to the proposal as a whole?

-Toshio

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Suggested ScriptletSnippets (icon cache) changes
 

On Saturday 14 February 2009, Toshio Kuratomi wrote:

> https://fedoraproject.org/wiki/PackagingDrafts/Icon_Cache
>
> Does that look good?

Yep, pretty much. I found some things that could be improved, and reworded
the first paragraph.

> Couple questions, in the %postun, there's no || : for the touch. Is
> that intentional?

Yes. Only the final exit statuses of the scriptlets matter here.

> If %posttrans should prove controversial (I don't see a problem but if
> it is) is including the gtk-update-icon-cache call in %post in its
> modified state acceptable to the proposal as a whole?

I'm not sure I understand you correctly. Do you mean that if %posttrans for
some reason is not accepted, just move the g-u-i-c call from %posttrans
to %post? I suppose that would work, but it would result in icons that are
removed on package upgrades left behind in the GTK icon cache. Dunno if
that's a problem at all, but my initial proposal did not have that issue:
https://www.redhat.com/archives/fedora-packaging/2009-January/msg00138.html

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging