%checks framework standardisation idea proposal (Was: Static libraries in Fedora distribution)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(And yet another resend as it has been send only privately)

On 17 March 2017 at 08:29, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
It is really not so simple. :-)

Running GDB testsuite in Koji was crashing the build hosts as they were
running on older RHEL kernels with ptrace bugs.  Hopefully they all run recent
enough RHELs now but I did not check (=read /proc/version from *.spec).

Wow!! :)

But besides that the testsuite from Koji was + would be too unrealiable to use
as GDB testsuite is very sensitive to machine load.  And you cannot guarantee
no other rpms get built on the same Koji host as your rpm.  So I run the
testsuite only on machines under my control using --with testsuite.

So in such gdb special case default it should be in spec "%bcond_with check" (yes .. "with" is disabling bcond declaration and "without" is enabling it :) ) to disable %check and force over rpmbuild {--check|--with check} to force execute %check manually.

Because standard/vanilla rpmbuild has already now --nocheck option already.
Because it is %check section IMO consequently/logically it should be on to of this --check and "%bcond_with{,out} check" and as well CheckRequires.
Above will be working as well with "--with{,out} check" currently possible to use command line options.

You may say one may completely drop any testsuite runs from the gdb.spec and
run it all only externally from some extra scripts.  But that is inconvenient
for me (and Red Hat QA) as we deal with so many GDB releases for many
RH OSes/versions/arches/variants that it is most convenient to keep all the
testing pre-requisites + rules in one gdb.spec for the GDB variant under test.

No no .. it is misunderstanding.
Currently in different spec files you may find:

%define <foo> 0
.
%if 0%{<foo>:1}
Buildrequires: <bar>
%endif
.
%if 0%{<foo>:1}
%check
%{__make} check
%endif

or:

%check
%if 0%{<foo>:1}
%check
%{__make} check
%endif

Sometimes instead:

%define <foo> 0

is used:
%bcond_without <foo>

and:

%if %{with <foo>}
%check
%{__make} check
%endif

All above is hard to read to catch by our brains any inconsistencies basing on humans natural abilities easy recognize patterns or breaking patterns.
All leaving beings on Earth relies on those abilities formed by hundreds millions of years evolution of life .. so we as humans should be using such evolution baggage as often as it is only possible :)

In other words .. Fedora current reality is there is no at the moment real spec files standardisation about how such bits should be implemented in spec files and depends on people skills some packages are implementing such bits very strangely.

Again: all %ifings makes really spec files less readable.
My proposition removes completely ALL %ifings because it would be only:

%bcond_with{,out} check

CheckRequires: <foo>
CheckRequires: <bar>
 
%check
%{__make} check

Do you see this now that it is much better readable/cleaner/shorter?
This syntax could be easy to plug into our evolutionary patterns abilities :D

Such warian does not require any %ifings making whole spec description purely declarative.

"rpmbuild -ba <foo>.spec" will cause that during execution of such command system must have installed all BuildRequires and CheckRequires.
For example "rpmbuild -bc --short-circuit <foo>.spec" may even automatically disable CheckRequires.

My proposition opens doors as well on possibility execution of "rpmbuild -bp --nodeps {--with check|--check} --define 'prep %dump' <foo.spec>".
And doesn't matter what is the spec layer setting about use or not use %check from %dump output would be possible easy extract only %check stage additional dependencies.
Maybe it is not obvious but this trick/technique with "--define 'prep %dump'" allows process only spec files without any sources, patches or installed dev tools.
In such scenario nothing from any spec file sections is executed as well.

With any %ifings extraction %check dependencies with or without %dump trick is/will be way harder.
So my proposal is about architecting proper platform for other use cases than pure build packages.

IMO spec files should be as much declarative as it is only possible because such approach makes may things around much easier or even sometimes at least possible without calling rocket scientists.

> So probably now is clear that with %ifed BuildRequires (like it is now)
> everything would be way harder.

Just include --with testsuite to Fedora Packaging Guidelines instead of new
CheckBuild keyword.  I have seen also --with check to be used.

Correction: s/CheckBuild/CheckRequires/ (sorry I've been writing this reply at 3am)

It would would be not a keyword but dependency field like existing Requires, Requires([post|posun|pre|preun) and BuildRequires.
CheckRequires would indicating special dependencies only to have successful %check section stage execution.
Typical case is that %check has some additional set of dependencies which are longer than BuildRequires list.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux