I've nothing against adding more brp-scripts as such, I haven't looked at this
in any detail but there seems to be useful stuff in there.
Enabling such a big pile of new stuff by default is a wholly different
question, but lets not get hung up on that. The other complaint wrt enablement
is that "dont" as a disabler doesn't sound right, "brp" stands for build root
policy and enable/disable seem more fitting terminology for that. On a related
note, whatever the means of enabling and disabling these policies ends up
being, it needs to cover the pre-existing policies too, but that's beyond the
scope of this PR. Neither of these issues prevents getting the scripts
themselves in.
I do have some issues with the script names, they're fairly hodge-podgey and
not very descriptive in places. Not that the ones currently upstream truly
follow any defined pattern but lets not make that situation worse.
On a related note, looking at this many brp-scripts at once makes it painfully
obvious how stupid the whole mechanism is. Every script repeats the same work
over and over again, so we end up checking for buildroot and running find after
find after find. I'd think all this could be coupled with the file classifier:
eg the file classifier already knows if there are ELF files in the buildroot,
and we could use that info to only run ELF-related brp-scripts when actually
needed. Etc.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/122#issuecomment-282259094
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
