On Mon, Jul 9, 2018 at 7:53 PM, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
>>>>> "KF" == Kevin Fenzi
<kevin(a)scrye.com> writes:
KF> I agree. If this could be done before mass rebuild we can catch any
KF> issues/typos/mistakes in this with the mass rebuild.
I've been away from computers for a bit, but I could certainly do this
without too much effort. I just know that some people are somewhat...
prickly about "their" packages and wanted to give some room for
discussion. But I will just go ahead and fix at least a big batch of
these previous to the rebuild. If someone really, really doesn't like
it then I guess they can revert, but I do intend to keep running this
and the rest of the reports I've been running recently.
Also, the reason gdb didn't show up is because it uses yet another form
of the line which I didn't account for: %defattr(-,root,root). The fact
that there are so many forms and most couldn't tell you which arguments
are which (and yet copy it into their specfiles because some other
specfile has it) is more than sufficient reason for removing it.
Anyway, modifying the check for that additional defattr mode adds 306
packages (not including gdb because it was fixed). That list (in the
usual format) is below.
Finally, the checks I'm doing aren't intended to be comprehensive. It
only looks for one specific case. After this is done I may work on
auditing all of the remaining uses of defattr.
Would you please post, or post a link to, your updated filter script?
I'd be especially curious if it inserts a record of the work in the
%changelog stanza.
As good as you may be at writing such tools, I'd be a bit wary of "I
have this script that's touching hundreds or thousands of spec files,
and which I've updated again, and no one has seen the final form, but
you can verify my work by checking the thousands of modified RPM's
I've built". It seems somewhat risky.