History from the FreeBSD project showed that automating static analysis tools
during build just leads to gigabytes of information that slowly composts
because fixing warnings from static analysis is a Sisyphean task. The issue I
am pointing out is that static analysis should NOT be run on every rpm build,
there's simply too many warnings to handle.
Meanwhile, rpmbuild already classifies files and passes (executable) content
for dependency extraction. That same mechanism could be extended for static
analysis on scripts. Just as easily,
rpmlint could/should be modified to automate static analysis on distributed
python/bash scripts.
Doing C static analysis needs more context than a single file and is usually
done like in coverity, by adding a wrapper to an existing build using envier's.
There is nothing in a *spec file that prevents coverity-style static analysis
during an rpmbuild. Again, the volume of warnings/errors usually is large
enough to make the automation nothing more than an annoyance.
--
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/issues/306#issuecomment-323542730
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
