[Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache

[Tomasz Kłoczko]

Hi,

I'm trying to follow procedure described on
https://fedoraproject.org/wiki/Mass_package_changes

Description of the current state
=======================

At the moment more than many spec files have %post/%postu/%postrans
scriptles in which is done updating hicolor theme cache by calling:

gtk-update-icon-cache -f %{_datadir}/icons/hicolor

All those scriptles are no longer needed because in hicolor-icon-theme
package has file triggers updating theme cache on any change in single
dnf/rpm transaction.

$ rpm -q --filetriggers hicolor-icon-theme
transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :

Remove all those %post/%postu/%postrans scriptles will speedup install
and upgrades as only one time gtk-update-icon-cache will be executed
as hicolor-icon-theme transaction action.

List of affected packages
===================
On the list is more than 1300 packages.
List has been generated in directory with all spec files extracted
from git repos using command:

$ grep 'gtk-update-icon-cache.*hicolor' * | grep -v hicolor-icon-theme
| awk -F\. '{print $1}' | uniq > gtk-update-icon-cache_hicolor.lst

gtk-update-icon-cache_hicolor.lst has been added as the attachment in
this email.


If it will be no more comments about this proposal I'll try in a week
follow next steps of the procedure described on Fedora wiki sending
final proposal to devel-announce list and after this raise ticket in
BTS.

PS. Please advise how to implement change without raising +1300
tickets on bugzilla (I'm not going to sped weeks or months on
introduce such simple change)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Igor Gnatenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, 2018-01-03 at 16:53 +0100, Tomasz Kłoczko wrote:
>  Hi,
>  
>  I'm trying to follow procedure described on
>  https://fedoraproject.org/wiki/Mass_package_changes
>  
>  Description of the current state
>  =======================
>  
>  At the moment more than many spec files have %post/%postu/%postrans
>  scriptles in which is done updating hicolor theme cache by calling:
>  
>  gtk-update-icon-cache -f %{_datadir}/icons/hicolor
>  
>  All those scriptles are no longer needed because in hicolor-icon-theme
>  package has file triggers updating theme cache on any change in single
>  dnf/rpm transaction.
>  
>  $ rpm -q --filetriggers hicolor-icon-theme
>  transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
>  gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
>  transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
>  gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
>  
>  Remove all those %post/%postu/%postrans scriptles will speedup install
>  and upgrades as only one time gtk-update-icon-cache will be executed
>  as hicolor-icon-theme transaction action.
>  
>  List of affected packages
>  ===================
>  On the list is more than 1300 packages.
>  List has been generated in directory with all spec files extracted
>  from git repos using command:
>  
>  $ grep 'gtk-update-icon-cache.*hicolor' * | grep -v hicolor-icon-theme
>  > awk -F\. '{print $1}' | uniq > gtk-update-icon-cache_hicolor.lst
>  
>  gtk-update-icon-cache_hicolor.lst has been added as the attachment in
>  this email.
>  
>  
>  If it will be no more comments about this proposal I'll try in a week
>  follow next steps of the procedure described on Fedora wiki sending
>  final proposal to devel-announce list and after this raise ticket in
>  BTS.
>  
>  PS. Please advise how to implement change without raising +1300
>  tickets on bugzilla (I'm not going to sped weeks or months on
>  introduce such simple change) 
First thing you should do is to open a ticket for FPC[0] in order to fix
guidelines.

Once it is approved by FPC, I can help you dealing with this as a proven
packager since it is trivial enough.

[0] https://pagure.io/packaging-committee
- -- 
- -Igor Gnatenko
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpNAC8ACgkQaVcUvRu8
> X0w27A//dbQxuRtpHRMaM090WVRz7fyvXLAbDXN42/Au8OgmKuB4tHrF0lH09GN4
> XnW8dBjJDMkRRTjeQ1Hofj6Iq1h+dWRcpc+jXSzaRtBdojT64mAotQD0j2ScmqWo
> hsu9nMNhsQYaAJJb68O8jRy8K7+kN2e+MS0jYEMOR2nubUr/pPd/AMs1170kgddG
> S59lwpZB3zdJlsyIcCbRTk54Ls/rB84nAz+8bJi32qxRPVZxcOY/AtIQowx8GxNE
> bC8kqYV8zrI7gQNScg1mrjkCBZDWXAVZ/pz/3Bckv55TchzIof8/Q6fIzc6KVblv
> j5dWx8KqiBbDhrAPWlo6d+m29KVbjWO5T3Kv1348yLh4W74ZNDlVsiCWtyVIYiIj
> ukDJMAy4Y84z72A0l/DC8HRbV2rJOWkw2F/NVVeZbvphP/tfkAM7n+ra6EaUuMe9
> /LU8vMq6zJpDsokpeBnuP6rdg9KB2DYKCUVT/H0eTvvkOq7Z0xSFbkQobDR/D62n
> yu2hg5zzXwS0qRgLYqpOIOXyLxHLbeG6N54VohuSPGDf/Pq2Y/w+W/5tolY5SrIW
> U1ltvAVHZ1CvKJeTA3kiVGSU8ej62XbXKd+impcfxgkJSixNBANoyr3abp7LdhG+
> Gbd/HDpJCC6gIPLXmhejQKoImlT0qax98+pHe9araMqt/HFqLZ8=
> =/ELg
> -----END PGP SIGNATURE-----

[Tomasz Kłoczko]

On 3 January 2018 at 17:09, Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org&gt; wrote:
[..]
>  First thing you should do is to open a ticket for FPC[0] in order to
> fix
>  guidelines.
>
>  Once it is approved by FPC, I can help you dealing with this as a proven
>  packager since it is trivial enough. 
Done https://pagure.io/packaging-committee/issue/736

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 03, 2018 at 05:33:38PM +0100, Tomasz Kłoczko wrote:
>  On 3 January 2018 at 17:09, Igor Gnatenko
>  <ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  [..]
>  > First thing you should do is to open a ticket for FPC[0] in order to fix
>  > guidelines.
>  >
>  > Once it is approved by FPC, I can help you dealing with this as a proven
>  > packager since it is trivial enough. 
Count me in too, I'd be happy to help.

>  Done https://pagure.io/packaging-committee/issue/736 
Once the guidelines are removed, I think the optimum way is to
a) generate patches for all 1300 packages
b) post them publicly
c) allow the public-at-large and a few committed people to review them
d) after a week of delay use pp powers (you now have at least two
   volunteers, so this shouldn't be an issue) to push those changes
   directly to distgit
e) rebuild select packages (maybe one hundred, to test for any regressions).

Why not rebuild all packages? This is a trivial change, and a mass
rebuild is coming up anyway, so there doesn't seem to be a need to
rebuild everything twice.

Why not post PRs? 1300 PRs will be a pain to manage. It'll also put
a big strain on pagure. I think PRs should be reserved for stuff that
we _want_ people to review individually, not for mass changes like
this.

As to the specific way to implement point a): either the tools
mentioned by Charalampos or Neal, or maybe even a simple 'sed -i'
+ 'rpmdev-bumpspec' would work. I expect that the only way that
doesn't require too much thinking or time is to identify the few
common patterns that are used to call gtk-update-icon-cache and
turn them verbatim into a huge search&replace invocation. This should
work for 99% of packages, and the remaining ones can be done by hand.

Zbyszek

[Tomasz Kłoczko]

On 3 January 2018 at 18:16, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
[..]
> > Done https://pagure.io/packaging-committee/issue/736
>
>  Once the guidelines are removed, I think the optimum way is to
>  a) generate patches for all 1300 packages
>  b) post them publicly
>  c) allow the public-at-large and a few committed people to review them
>  d) after a week of delay use pp powers (you now have at least two
>     volunteers, so this shouldn't be an issue) to push those changes
>     directly to distgit
>  e) rebuild select packages (maybe one hundred, to test for any regressions). 
Thank you drafting next steps which needs to be done.
Will try to follow.

>  Why not rebuild all packages? This is a trivial change, and a mass
>  rebuild is coming up anyway, so there doesn't seem to be a need to
>  rebuild everything twice. 
Totally agree.
Maybe it was not obvious but my original though was introduce it using
as simple way as it is only possible then after commit imminently push
all fixed packages to rebuild to confirm that none of those changes
(which many will be introduced more or less by manual modifications)
are affection at least correct build of those packages on official
builders.
This could minimize number of possible mistakes.

[..]
>  As to the specific way to implement point a): either the tools
>  mentioned by Charalampos or Neal, or maybe even a simple 'sed -i'
>  + 'rpmdev-bumpspec' would work. I expect that the only way that
>  doesn't require too much thinking or time is to identify the few
>  common patterns that are used to call gtk-update-icon-cache and
>  turn them verbatim into a huge search&replace invocation. This should
>  work for 99% of packages, and the remaining ones can be done by hand. 
I think that it it will be closer to 90% :)
Nevertheless I think that whole set of +1300 specs could be divided in
some batches in which first will go specs which can be corrected using
exact text substitution then in next steps all specs which needs to be
treated individually.

Just one more clarification that all those changes should start when
FPG will be updated and in %changelog should used the same text
pointing to new FPG rule or pagure ticket.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Jason L Tibbitts III]

> >>>> "IG" == Igor Gnatenko
> <ignatenkobrain(a)fedoraproject.org&gt; writes: 
IG> First thing you should do is to open a ticket for FPC[0] in order to
IG> fix guidelines.

I'm still catching up on list mail but someone sent me a personal email
about this.  Not sure why they didn't open a ticket, but in the end it
doesn't matter.  I did see that even in F26 that icon cache stanza is
not needed and so I went ahead and moved that bit to the EPEL:Packaging
page.

 - J<

[Robert-André Mauchin]

On vendredi 5 janvier 2018 18:21:59 CET Jason L Tibbitts III wrote:
>  >>>>> "IG" == Igor Gnatenko
> <ignatenkobrain(a)fedoraproject.org&gt; writes:
>  
>  
>  IG> First thing you should do is to open a ticket for FPC[0] in order to
>  IG> fix guidelines.
>  
>  I'm still catching up on list mail but someone sent me a personal email
>  about this.  Not sure why they didn't open a ticket, but in the end it
>  doesn't matter.  I did see that even in F26 that icon cache stanza is
>  not needed and so I went ahead and moved that bit to the EPEL:Packaging
>  page.
>  
>   - J< 
I sent the personal email before I found out about this thread, it was during 
a review for a package from Rex Dieter that he poinsed out that hicolor-icon-
theme had transfiletrigger and that the guidelines were outdated.

Robert-André

[Johannes Lips]

Would have been nice to get some more background information than just the git commit
message. Then one needs to do research to find this thread and the related ticket. I
don't have time to follow all the discussions/tickets on devel or anywhere else, but
this is even more time consuming. Especially, since it was just updated on the very same
day, so actively maintained and I don't really see the need for a provenpackager to
step in. Why not follow a more regular workflow with bug reports or whatever.

Cheers
Johannes

[Tomasz Kłoczko]

On 19 January 2018 at 18:42, Johannes Lips <johannes.lips(a)gmail.com&gt; wrote:

>  Would have been nice to get some more background information than
> just the
>  git commit message. Then one needs to do research to find this thread and
>  the related ticket. I don't have time to follow all the discussions/tickets
>  on devel or anywhere else, but this is even more time consuming.
>  Especially, since it was just updated on the very same day, so actively
>  maintained and I don't really see the need for a provenpackager to step in.
>  Why not follow a more regular workflow with bug reports or whatever.
>  
All is here https://pagure.io/packaging-committee/issue/736

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Johannes Lips]

Well, of course, but the issue is not the change itself or anything. It's just the
implementation and the lack of information for the maintainer. 
The maintainer just sees a git commit without additional information other than the
scriplets are obsolete, which is not a lot to be honest. I would have preferred a
heads-up, especially since it's nothing urgent.

johannes

[Tomasz Kłoczko]

On 20 January 2018 at 07:23, Johannes Lips <johannes.lips(a)gmail.com&gt; wrote:

>  Well, of course, but the issue is not the change itself or anything.
> It's
>  just the implementation and the lack of information for the maintainer.
>  The maintainer just sees a git commit without additional information other
>  than the scriplets are obsolete, which is not a lot to be honest. I would
>  have preferred a heads-up, especially since it's nothing urgent.
>  
Agree with you.
This why I've proposed in the ticket %changelog entry :)

Proposed %changelog entry note:

"- 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)"

(just found that in the ticket was repeating word so above is clean version
of such entry)

IMO next time on any mass updates part of the approval procedure should be
review %changelog entry before start changing first spec.
All to make sure that whoever will feel surprised will be able to go to
some URL to read longer explanation (wiki page or at least ticket URL).

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Charalampos Stratakis]

----- Original Message -----
>  From: "Tomasz Kłoczko" <kloczko.tomasz(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Wednesday, January 3, 2018 4:53:24 PM
>  Subject: [Proposal] Mass change: remove executing gtk-update-icon-cache in
> %post/%postu/%postrans to update hicolor
>  theme cache
>  
>  Hi,
>  
>  I'm trying to follow procedure described on
>  https://fedoraproject.org/wiki/Mass_package_changes
>  
>  Description of the current state
>  =======================
>  
>  At the moment more than many spec files have %post/%postu/%postrans
>  scriptles in which is done updating hicolor theme cache by calling:
>  
>  gtk-update-icon-cache -f %{_datadir}/icons/hicolor
>  
>  All those scriptles are no longer needed because in hicolor-icon-theme
>  package has file triggers updating theme cache on any change in single
>  dnf/rpm transaction.
>  
>  $ rpm -q --filetriggers hicolor-icon-theme
>  transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
>  gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
>  transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
>  gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
>  
>  Remove all those %post/%postu/%postrans scriptles will speedup install
>  and upgrades as only one time gtk-update-icon-cache will be executed
>  as hicolor-icon-theme transaction action.
>  
>  List of affected packages
>  ===================
>  On the list is more than 1300 packages.
>  List has been generated in directory with all spec files extracted
>  from git repos using command:
>  
>  $ grep 'gtk-update-icon-cache.*hicolor' * | grep -v hicolor-icon-theme
>  | awk -F\. '{print $1}' | uniq > gtk-update-icon-cache_hicolor.lst
>  
>  gtk-update-icon-cache_hicolor.lst has been added as the attachment in
>  this email.
>  
>  
>  If it will be no more comments about this proposal I'll try in a week
>  follow next steps of the procedure described on Fedora wiki sending
>  final proposal to devel-announce list and after this raise ticket in
>  BTS.
>  
>  PS. Please advise how to implement change without raising +1300
>  tickets on bugzilla (I'm not going to sped weeks or months on
>  introduce such simple change)
>  
>  kloczek
>  --
>  Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>   

Hi.

You might want to take a look at https://pagure.io/python-fixrequires which is from a
python-SIG member, and modify it for your usecase.

It basically forks a repo, makes the changes to the SPEC, pushes it to your fork and
creates a PR to the original repo.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat

[Philip Kovacs]

Can we remove the gtk-update-icon-cache entries from our packages now, manually, in
advance of the mass update?   

    On Wednesday, January 3, 2018 11:10 AM, Charalampos Stratakis
<cstratak(a)redhat.com&gt; wrote:
 

 ----- Original Message -----
>  From: "Tomasz Kłoczko" <kloczko.tomasz(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Wednesday, January 3, 2018 4:53:24 PM
>  Subject: [Proposal] Mass change: remove executing gtk-update-icon-cache in
> %post/%postu/%postrans to update hicolor
>  theme cache
>  
>  Hi,
>  
>  I'm trying to follow procedure described on
>  https://fedoraproject.org/wiki/Mass_package_changes
>  
>  Description of the current state
>  =======================
>  
>  At the moment more than many spec files have %post/%postu/%postrans
>  scriptles in which is done updating hicolor theme cache by calling:
>  
>  gtk-update-icon-cache -f %{_datadir}/icons/hicolor
>  
>  All those scriptles are no longer needed because in hicolor-icon-theme
>  package has file triggers updating theme cache on any change in single
>  dnf/rpm transaction.
>  
>  $ rpm -q --filetriggers hicolor-icon-theme
>  transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
>  gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
>  transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
>  gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
>  
>  Remove all those %post/%postu/%postrans scriptles will speedup install
>  and upgrades as only one time gtk-update-icon-cache will be executed
>  as hicolor-icon-theme transaction action.
>  
>  List of affected packages
>  ===================
>  On the list is more than 1300 packages.
>  List has been generated in directory with all spec files extracted
>  from git repos using command:
>  
>  $ grep 'gtk-update-icon-cache.*hicolor' * | grep -v hicolor-icon-theme
>  | awk -F\. '{print $1}' | uniq > gtk-update-icon-cache_hicolor.lst
>  
>  gtk-update-icon-cache_hicolor.lst has been added as the attachment in
>  this email.
>  
>  
>  If it will be no more comments about this proposal I'll try in a week
>  follow next steps of the procedure described on Fedora wiki sending
>  final proposal to devel-announce list and after this raise ticket in
>  BTS.
>  
>  PS. Please advise how to implement change without raising +1300
>  tickets on bugzilla (I'm not going to sped weeks or months on
>  introduce such simple change)
>  
>  kloczek
>  --
>  Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>   

Hi.

You might want to take a look at https://pagure.io/python-fixrequires which is from a
python-SIG member, and modify it for your usecase.

It basically forks a repo, makes the changes to the SPEC, pushes it to your fork and
creates a PR to the original repo.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Igor Gnatenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, 2018-01-03 at 16:30 +0000, Philip Kovacs wrote:
>  Can we remove the gtk-update-icon-cache entries from our packages
> now,
>  manually, in advance of the mass update?    
Before FPC approves that it's really not needed, strictly speaking is violation
of packaging guidelines...
- -- 
- -Igor Gnatenko
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpNB7sACgkQaVcUvRu8
> X0zcMg//Yk5YBNJ0GNrPMOOzu5y8ROIrmOLSt0lFmRH0zRI8Dj2BcLz7oG26vrjp
> +w7cULbrGIC04gl/QjZxlSr0COJO0o5vV9hp57p9wxnQigzlHzyMOZhgpD0Ngwci
> CMKqG0/zS5ffa1L42ZOlx8c9MbmTVEgTgIRu5yPuEetBGtSrH/HlbpDhewNmgtem
> KurCJFFrKrDHAs6GHTLFJIz16HpV8ufKxKQrLABWW95s1RTIaQVIFBOHVFnr8BwZ
> YdpMVgWqoYiBUKfdCkPud6nXiiv4FAluaZKFZGfnsN1v4sDX02cttDqp9rO+pEtA
> 1UHdS41x0Vj2gfZKZcwt7tPSYfOChtFaExdA5XE+S3+LEUtSMUJVI6ubZZu428eu
> iNKA15c4eNrt3DLx9b60WvV4rKnD0w384qNhYgYyXDVbPlSmX01cfF3fN2ozf8Pi
> vgO0oOAHpAHH2RM3bIHWkI+VIz3kbrXrKuZu7KQb8rPiRaws6unLpfZYLyZn+QfW
> //+cwiOA6FSJdj6RAS9fzJaGG5qFW01VL5FxkamnL6WfUAL4mXhgLfjJPd8NaCyT
> Ko4SOXA91rU9T3pWXv2F1VX0K53G2IYRHxadnn8ZWLDwX4QcRw4pE6TTKY2owZfp
> 1/Cnu3MMD4+4fQfZKxuipEFF0+/R85AOP5C8QxSB+VDz5U7JN74=
> =hAPc
> -----END PGP SIGNATURE-----

[Tomasz Kłoczko]

On 3 January 2018 at 17:41, Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org&gt; wrote:
[..]
> > Can we remove the gtk-update-icon-cache entries from our packages
> now,
> > manually, in advance of the mass update?
>
>  Before FPC approves that it's really not needed, strictly speaking is violation
>  of packaging guidelines... 
Just added comment on pagure.io ticket that this case could be a bit
more generic.
Yes, it is possible to remove all gtk-update-icon-cache from
%post/%postu/%postrans and replace them all by file triggers in main
themes packages like it is now in hicolor-icon-theme package.
So IMO Fedora documentation should be modified more in this direction
and those +1300 spec files about hicolor theme icons cache update it
is only ATM biggest part of such simplifications.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Tomasz Kłoczko]

Tomasz Kłoczko | Tel: [phone] | LinkedIn: http://lnkd.in/FXPWxH


On 3 January 2018 at 18:08, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt; wrote:
[..]
>  So IMO Fedora documentation should be modified more in this
> direction
>  and those +1300 spec files about hicolor theme icons cache update it
>  is only ATM biggest part of such simplifications. 
Here is single number which shows scale of the issue outside of the
case with hicolor theme updates.

[tkloczko@domek SPECS.fedora]$ grep 'gtk-update-icon-cache' * | grep
-v hicolor | awk -F: '{print $1}' | uniq | wc -l
312

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Jason L Tibbitts III]

> >>>> "IG" == Igor Gnatenko
> <ignatenkobrain(a)fedoraproject.org&gt; writes: 
 
IG> Before FPC approves that it's really not needed, strictly speaking
IG> is violation of packaging guidelines...

I hope we're not so bureaucracy minded that we can't ignore obviously
wrong things because they're on a wiki page that just hasn't been
updated to match reality.  The caveat is, of course, that if you plow
ahead with a solution, you have to make sure that said solution was
actually adopted in the end, or is compatible with what was adopted.
But in this case, nothing is replacing the removed scriptlets.

 - J<

[Fabio Valentini]

So, if I am reading this correctly:

1) Triggers have been added to hicolor-icon-theme in all supported fedora
releases (f26+),
2) the scriptlets are no longer necessary in packages installing hicolor
icons, and
3) references to the scriptlets have been removed from the packaging
guidelines.

According to that, it should be OK for me to start removing them from my
packages.
Please correct me if I'm wrong, otherwise I'll start doing exactly that, as
I've been waiting to get rid of that gunk for some time.

Fabio

On Fri, Jan 5, 2018 at 6:35 PM Jason L Tibbitts III <tibbs(a)math.uh.edu&gt;
wrote:

>  >>>>> "IG" == Igor Gnatenko
> <ignatenkobrain(a)fedoraproject.org&gt; writes:
>
>  IG> Before FPC approves that it's really not needed, strictly speaking
>  IG> is violation of packaging guidelines...
>
>  I hope we're not so bureaucracy minded that we can't ignore obviously
>  wrong things because they're on a wiki page that just hasn't been
>  updated to match reality.  The caveat is, of course, that if you plow
>  ahead with a solution, you have to make sure that said solution was
>  actually adopted in the end, or is compatible with what was adopted.
>  But in this case, nothing is replacing the removed scriptlets.
>
>   - J<
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Tomasz Kłoczko]

On 3 January 2018 at 17:09, Charalampos Stratakis <cstratak(a)redhat.com&gt; wrote:
[..]
>  You might want to take a look at https://pagure.io/python-fixrequires
> which is from a python-SIG member, and modify it for your usecase.
>
>  It basically forks a repo, makes the changes to the SPEC, pushes it to your fork and
> creates a PR to the original repo. 
I don't think that this could be used because each change needs to be
reviewed before commit.

All because only standard of writing spec file is there-is-no-standard.
IMO it should be implemented some kind of spec indentation script
which will make all disputes about spec styles pointless as all specs
should be formatted in the same way.
Many years ago when I've been working on PLD we wrote such spec
indentation tool using few KB awk script. using this script was
possible to keep the same style across all spec files with:
- put in exact order spec fields in spec preamble
- format all %description to 80 cols
- put in spec exact order of %packages and %files sections
- substitute exact strings to use macros

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Neal Gompa]

On Wed, Jan 3, 2018 at 11:42 AM, Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com&gt; wrote:
>  On 3 January 2018 at 17:09, Charalampos Stratakis
> <cstratak(a)redhat.com&gt; wrote:
>  [..]
> > You might want to take a look at https://pagure.io/python-fixrequires which is from a
> python-SIG member, and modify it for your usecase.
> >
> > It basically forks a repo, makes the changes to the SPEC, pushes it to your fork and
> creates a PR to the original repo.
>
>  I don't think that this could be used because each change needs to be
>  reviewed before commit.
>
>  All because only standard of writing spec file is there-is-no-standard.
>  IMO it should be implemented some kind of spec indentation script
>  which will make all disputes about spec styles pointless as all specs
>  should be formatted in the same way.
>  Many years ago when I've been working on PLD we wrote such spec
>  indentation tool using few KB awk script. using this script was
>  possible to keep the same style across all spec files with:
>  - put in exact order spec fields in spec preamble
>  - format all %description to 80 cols
>  - put in spec exact order of %packages and %files sections
>  - substitute exact strings to use macros 
For a while, I've been thinking about porting over the excellent
spec-cleaner[1] tool from openSUSE for doing this with Fedora
packages.

I may actually decide to do this, depending on how much spare time I can muster.

[1]: https://github.com/openSUSE/spec-cleaner

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Tomasz Kłoczko]

On 3 January 2018 at 18:08, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
[..]
> > Many years ago when I've been working on PLD we wrote such
> spec
> > indentation tool using few KB awk script. using this script was
> > possible to keep the same style across all spec files with:
> > - put in exact order spec fields in spec preamble
> > - format all %description to 80 cols
> > - put in spec exact order of %packages and %files sections
> > - substitute exact strings to use macros
>
>  For a while, I've been thinking about porting over the excellent
>  spec-cleaner[1] tool from openSUSE for doing this with Fedora
>  packages.
>
>  I may actually decide to do this, depending on how much spare time I can muster.
>
>  [1]: https://github.com/openSUSE/spec-cleaner 
This tool is doing so many things that it would be really hard to
adapt it to not trash some number of spec files.

In attachment you can find this script which was used in PLD.
Maybe after align/indent all Fedora spec using such simpler filter
will be possible to use something more complicated/sophisticated.

I'm only suggesting to consider way in which not all indentation/style
changes will be introduced in one go ..

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Adam Williamson]

On Wed, 2018-01-03 at 17:42 +0100, Tomasz Kłoczko wrote:
>  On 3 January 2018 at 17:09, Charalampos Stratakis
> <cstratak(a)redhat.com&gt; wrote:
>  [..]
>  > You might want to take a look at https://pagure.io/python-fixrequires which is from
> a python-SIG member, and modify it for your usecase.
>  > 
>  > It basically forks a repo, makes the changes to the SPEC, pushes it to your fork and
> creates a PR to the original repo.
>  
>  I don't think that this could be used because each change needs to be
>  reviewed before commit.
>  
>  All because only standard of writing spec file is there-is-no-standard.
>  IMO it should be implemented some kind of spec indentation script 
<snip>

No. Please don't conflate these issues - primarily for your own sanity.

Moving icon cache updates to a trigger in the icon theme package is a
very clear and obvious technical improvement which we absolutely ought
to do as soon as possible.

Trying to impose some sort of stylistic consistency on spec files, at
this point in time, feels like a gigantic tarpit trap which will eat
the next several months of your life and sap large chunks of
motivation.

If you still want to do it, I mean, you do you, but it would be a
*terrible* idea to bundle clear and obvious technical improvements in
with the idea of some kind of spec style guide (and enforcement).
Please treat it as an entirely separate proposal. Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net