(Resending below as looks like I've replied only to Jan)

On 16 March 2017 at 18:01, Jan Kratochvil <jkratoch@redhat.com> wrote:
On Thu, 16 Mar 2017 01:32:06 +0100, Tomasz Kłoczko wrote:
> OK here is full list of spec files which have glibc-static in BuildRequires:
>
> ./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local}

This is a false positive as it is enclosed by:
        %if 0%{?_with_testsuite:1}

I have no idea how common it may be but your grep could check %ifs.

I saw already such tweaks in many Fedora specs %check sections.
IMO such %ifing inside or around %check is incorrect/not needed and can be removed.
Why? Because:
- all possible to use package tests should be by default enabled
- if rpm packager want to speedup generate binary packages avoiding execution of %check section it is already possible to do this without spec file %ifing by use --nocheck rpmbuild option.

However IMO still few things are missing in whole %check framework:
- rpm spec file syntax should be extended to add CheckRequires: dependencies.
- second part missing in this picture is "bcond_with{,out} check" to have possibility hardcode disable %check if for example package produces 100% healthy package(s) but test suit is broken and when package will be pushed to official build systems %check should be disabled.

Of course --nocheck should disable using all CheckRequires dependencies and --nocheck should change "check" bcond state.

If someone will ask me why CheckBuild dependencies are better than currently used bconds around some BuildRequires here is my answer.
rpm provides some not well known way to dump all possible informations about all properties of the spec file.
Just to test this try to execute "rpmbuild -bp --nodeps --define 'prep %dump' <foo>.spec"
Such output is way easier to parse to for example start feeding using those informations some database to start doing some nasty queries against such data on a scale of whole distribution.
With separated CheckBuild dependencies it would be possible to produce exact check list dependencies list in oneliner using above duping technique.
So probably now is clear that with %ifed BuildRequires (like it is now) everything would be way harder.

Such hooking point to dump spec file parser data could be as well used as yet another koji regression test unit which will be tracking changes in spec files between releases/version/archs.

And yet another small idea related to %check.
I know that many Fedora packages can be extended by add %check because original source trees provides some test suits.
IMO it would be good to identify full list of package spec files without %check to ask all those packages maintainers to check is it possible to add %check or confirm that package source tree does not provide test suite.
If rpm will be extended by add std "check" bcond such lack of of test suite could be marked by add explicit in spec disable use %check even if there is no %check section.

Just realized that add such std check bcond should be quite easy to implement by only changing macros provided in rpm-build package.
Probably will try to add this trivial change :)
Team such bcond with --nocheck commandline option would be a bit harder but add standardised way to disable use by default %check execution will be trivial ..
If --nocheck is done over popt macro still it may be easy to add it (I need to check rpm code).

BTW: what is the best Fedora method to preserve such ideas somewhere/somehow?
Bugzilla?
(I'm still learning Fedora WayOfDoingThings(tm) :) )
kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH