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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3 January 2018 at 18:16, Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux