Just to remind the evolution:
https://pagure.io/packaging-committee/issue/469 https://pagure.io/packaging-committee/issue/501
And here it went somehow completely of the track :/
https://pagure.io/packaging-committee/issue/509
Dne 5.5.2017 v 16:03 Tomasz Kłoczko napsal(a):
On 5 May 2017 at 13:45, Jun Aruga jaruga@redhat.com wrote:
$ mock -r fedora-rawhide-x86_64 --with=bootstrap *.src.rpm => _with_bootstrap can be used as --with=bootstrap $ mock -r fedora-rawhide-x86_64 --define '_with_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'need_bootstrap 1' *.src.rpm $ mock -r fedora-rawhide-x86_64 --define 'enable_test 1' *.src.rpm
Few general comments:
- rpmbuild by default executes %check scripts. This section should be
by default *enabled* except few well known cases like gdb (crashes koji) or other doing interactive tests. Disable %check on demand is possible by simple add --nocheck to rpmbuild parameters. No other macros/%bconds are needed. As firing %check is by default active adding any other conditional %ifing is redundant/not needed. In other words only for such cases when it is necessary to *disable by default fire test suit* additional %ifing logic should be used.
Of course it should be enabled by default. This is not elaborated in the guidelines, but there still applied "use your best judgement" I hope ...
- mock supports --nocheck switch and as the consequence in above
example commands should be only "--nocheck" if it is really needed. If bootstrapping needs to disable %check look below
"--nocheck" is nice, but does not disable the "check" dependency installation. There was probably some ticket requesting this, not sure ...
%{?_with_bootstrap: %global bootstrap 1}
Looking on above I have kind of impression that most of the Fedora packages don't know what is the difference between %define and %global. So %global should be used *only* when it is need to overwrite some macro which comes with system resources and other system macros needs to be reevaluated after such redefinition. In other words as long as there there is no anything about <foo> macro in "rpmbuild --showrc | grep <foo>" output should be used %define .. not the %global because it is about defining some macros used only in exact spec file
In existing Fedora spec files probably in +95% cases instead %global should be used %define
https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over...
- rpm supports more than 10 years %bconds which simplifies defining
and using conditionally activated parts of procedures implemented in spec files. So above quoted line should be never used and only %bcond declaration should be:
%bcond_with boostrap # disable bootstrap by default
(yes .. "%bcond_with foo" disables and "%bcond_without foo" enables foo) Examples how to use macros defined by %bcond:
%if %{with boostrap} BuidRequires: foo %endif
or:
%{?with_bootstrap:BuildRequires: foo}
%build %configure \ --%{?with_bootstrap:en}%{?!with_bootstrap:dis}able-bootstrap \ --<other switches>
or:
%build %configure \ --with%{!?with_boostrap:out}-bootstrap \ --<other switches> or --with-bootstrap%{!?with_boostrap:=off}
%files %{?with_boostrap:%{_bindir>/foo} %{!?with_boostrap:%{_bindir>/bar}
None of the %post/%postun/%pre/%preun/%posttrans* scripts needs to be surrounded by %ifing as exact %files section looks like:
%if %{with boostrap} $files boostrap <%files list> %endif
The same is about "%package boostrap" and all other boostrap subpackage fields. They don't need for example bootstrap additional %ifing as well.
(Above examples are for GNU auotools and it is easy to guess how this can be adapted for other build frameworks)
Sometimes during during bootstrap may be necessary to disable %check
%check %{?with_boostrap:%{__make} check}
no other logic disabling %check is needed because (again) whatever is possible to fire in %check if it is only possible to use should be *enabled* by default.
Summary: what is proposed in https://pagure.io/packaging-committee/issue/509 should be IMO refused.
May be we should go with the "%bcond_with bootstrap" ... I might update the draft from [1] or prepare different version for FPC.
Vít
[1] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....