@pmatilai requested changes on this pull request.
See above.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah this needs to interact with both _with_check and _without_check, and not
add semantics to %_without_check value. And for that, it'd seem that we need to
parse the spec before fiddling with these values as otherwise we can't know
about bcond's set in the spec.
It also needs a better commit
> I think this should set _with_check unless _without_check is defined already.
> Basically to have `%bcond_without check` by default without having to put it
> in all spec files. But still need to make sure that somebody defines
> `%bcond_without check`, this code won't override it.
That
I would like to avoid `nocheck`, because the common way to conditinalize would
be `%if %{without nocheck}` and that's just confusing to read.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
May be the macro should be renamed to not collide with the with/without
mechanism. The bcond mechnism assumes that the actual value is not set as a
macro but only on the command line and is basically read only within the spec.
If you set the macro itself having two of them can lead to the
I think this should set _with_check unless _without_check is defined already.
Basically to have `%bcond_without check` by default without having to put it in
all spec files. But still need to make sure that somebody defines
`%bcond_without check`, this code won't override it.
--
You are
signaling and controling whether %check is executed during build.
The macro can be set globally or in the spec file. The --nocheck
parameter of rpmbuild takes precedence, though. If --nocheck is
passed to rpmbuild the macro set accordingly. Otherwise it is set
to 0 if not defined previously.
