Need to note that it is about removing scriptlet from https://fedoraproject.org/wiki/Packaging:Scriptlets

To make this more concrete: the proposal is to remove the whole section called "Icon Cache", https://fedoraproject.org/wiki/Packaging:Scriptlets#Icon_Cache.

Looking on what is now on wiki I think that it would be better to rewrite this part to not use %post/%postu/%postran to update those caches and choose theme main package to place file triggers like it is in hicolor-icon-theme.

Listen in attached .lst files packages are only part of the packages which are updating icon caches.
Try "grep gtk-update-icon-cache * | grep -v hicolor" on all spec files and you can find few other themes which are updated in %post/%postu/%postran.

https://fedoraproject.org/w/index.php?title=Packaging%3AScriptlets&type=revision&diff=508538&oldid=500930

This can be closed now.

OK, I've done patching have all spec files which have update hicolor theme icons cache and probably today or tomorrow will try to attach to this ticket archive with the first batch of those fixes which will remove cleanly all scriptlets from those spec files.
I've not added to all those fixes %changelog entry and bumping release but this part will relatively easy.
Proposed %changelog entry note:
"- remove Remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor
theme cache as it is no longer needed (https://pagure.io/packaging-committee/issue/736)"

Now more important question needs to be answered.
Who and how will apply all those fixes?
Generate ~1300 git pull requests will cause that probably never all those patches will be committed.
Ideally all those fixes should be added. Wiki documentation is now corrected so everything is ready.

Other though:

• 1st batch of patches will only against specs which have to remove whole %post/%postu/%postrans scriptlets

• 2nd batch will be about the same but with remove "Require: hicolor-icon-theme"

• 3rd about against all specs with non-regular modifications like when after remove gtk-update-icon-cache execution was possible to convert %post/%postun to "%{post,postun} -p /sbin/ldconfig"

• I see much more such mass changes which could be done like remove from %post/%postu/%postrans glib-compile-schemas, update-desktop-database, gconftool-2. I'm going to get rid those executions as well but after finishing gtk-update-icon-cache cleanups.

Both ignatenkobrain and I can apply the patches to the spec file. Once your patches are ready, we'll announce them on the fedora-devel and wait a week and apply.

Looks like good plan.
Because it will be more than one person committing those patches will try to put all in smaller chunks with 100 patches per batch.

No, that's not helpful. There's no difference in applying 500 or 1000 patches, and coordinating who is doing what is too complicated. One person should apply them all once they are all ready.

Ugh, I've just realized that I missed updates to this ticket ....

I've already fixed some number of packages in semi-automated way (~300 of them), so i'm happily stopping this now and waiting for huge patchset ;)

That is OK .. will try to pull updates and rediff my changes :)

I see that it will be for me to complicated find what still is left.
I think that you should finish what you've already stated and I'll try only verify/confirm that nothing left :)

@kloczek, can you publish your scripts actually?

What kind of script?

For the record, I was sent a personal message about this before this ticket had been opened. Chatted about it at the last no-quorum meeting and just went ahead and removed the section from the guidelines since it's out of date. I did move a copy into the EPEL guidelines. I also fixed my one package that had these scriptlets.

Just found that not only hicolor icons theme updates can be removed.

[tkloczko@domek SPECS.fedora]$ grep transfiletriggerin * | grep icons
adwaita-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/Adwaita
breeze-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/breeze
breeze-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/breeze-dark
elementary-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/elementary
gnome-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/gnome
gnome-themes-standard.spec:%transfiletriggerin -- %{_datadir}/icons/HighContrast
hicolor-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/hicolor
mint-x-icons.spec:%transfiletriggerin -- %{_datadir}/icons/Mint-X
mint-y-icons.spec:%transfiletriggerin -- %{_datadir}/icons/Mint-Y
oxygen-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/oxygen
paper-icon-theme.spec:%transfiletriggerin -- %{_datadir}/icons/Paper

I'm not sure what else the FPC needs to do here. We've already removed the outdated section from the guidelines, so this ticket is done.

Yes, there are several icon-containing packages which have the file triggers. Removing those from Fedora packages is not within the scope of this committee.

It occurs to me that we should probably have a section about the file triggers an icon-containing package should have. I will open a separate ticket.

Correct me if I'm wrong but I think that it would be better to close this ticket after clean all specs.
Opening next ticket for other themes before finishing this one does not make to much sense as in many cases hicolor icons theme cache is mixed with other themes caches updates so these changes quite often are overlapping.

I can help clean this area as I have now few weeks break between contracts but I'm just normal package maintaining so far only one package.
I see many other possible changes/cleanups which after discuss could be done on the scale few hundreds to few thousands specs.
Q: do you think that should I try follow the path https://fedoraproject.org/wiki/Provenpackager_policy ?

I think that this ticket needs to be reopen.
1) Still more than half specs are not corrected
2) From my last note here few new packages added updating hicolor icon cache so looks like fact that such updates are no longer needed is not spread amongst packagers.

Here is list of packages which introduced recently update hicolor icons cache:

kde-gtk-config
kdeplasma-addons
kmenuedit
kscreen
ksysguard
kwin

I mean, you can keep opening this. OK, I won't close it. But at this point it doesn't have anything to do with this committee, so it will just further clutter our already cluttered ticket list.

This is not about cluttering anything.
Things which needs to be done under this ticket seems are stuck in the middle and another issue is that information about that FPG has been updated and those regenerate icons caches is no longer needed is not properly spread in form of announcement.
To be hones I don't remember any announcement in recent two years on fedora-devel about changes in FPG.
If anything is causing kind of cluttering it is lack of last step spreading information about FPG updates.

Other thing is that as I see that you may be busy I'm offering my help on making mass trivial changes like this one requested/reported in this ticket but I need help as well to vote on my proven packager application.

@tibbs not sure if you announced these cleanups in devel@. If not -- would be nice..

Also I don't see point in having this ticket in open state, it just clutters FPC ticket list.

And btw, I cleaned up all Fedora packages which had these scriptlets and didn't have epel* branches.

Please remove another obsolete sentence, too:
"Additionally, there are scriptlets for packages to use to update the icon cache to ensure that the Desktop files are able to load the included icon files. See Packaging:Scriptlets#Icon_Cache. "
https://fedoraproject.org/wiki/Packaging:Guidelines#Icon_tag_in_Desktop_Files

Next question is how to proceed with fedora-review tool. AFAIK f-r checks for availability of the obsolete scriptlets.

Guys did you finish all cleanups?
I still see a lot of unconditionally done hicolor theme icons cache updates.

Why are you asking that question of FPC? We aren't the ones doing the cleanups. (Which, of course, is why it's pointless that this ticket remain open.)

For the record, I removed the now-outdated sentence mentioned by @raphgro a few comments up.