Dne 9.5.2017 v 09:58 Vít Ondruch napsal(a):
>
> 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.
IOW, having the %bootstrap macro standardized is the most important
thing. If we can set it using --with=bootstrap, that is nice addition,
but not the most important thing.
Vít
>
> 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
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
