Dne 5.5.2017 v 16:50 Vít Ondruch napsal(a):
>
> Dne 5.5.2017 v 16:03 Tomasz Kłoczko napsal(a):
>> 4) 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.
Thinking about this over the weekend, I think we should keep setting the
%boostrap macro and use the %if conditions where necessary. The main
advantage of the %bootstrap macro is that you can set it externally. Let
me give an example.
You want to run initial build of your distribution in build system
(Koji). To enable bootstrapping of all packages, it is enough to have
some package which contains this file:
~~~
$ cat %{_rpmconfigdir}/macros.d/macros.bootstrap
%bootstrap 1
~~~
Once the buildroot is configured to contain such package, all the
subsequent builds will have this macro defined and hence the packages
will run their bootstrap build. This way, you can boostrap the
distribution, although the build system (Koji) does not support anything
like "--with=bootstrap".
If there is way to use --with=boostrap flag (either rpmbuild or mock
supports it), you can conventionally use it.
Actually, the guidelines should probably be extended. The packages build
using "boostrap" macro should be marked, i.e. there should be "Provides:
bootstrap_build()" or something similar to be able to find such packages
later.
Vít
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
