(Resending below as looks like I've replied only to Jan)
On 16 March 2017 at 18:01, Jan Kratochvil <jkrat...@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 <http://lnkd.in/FXPWxH>*
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
