| |
@@ -1566,26 +1566,17 @@
|
| |
[#bootstrapping]
|
| |
== Bootstrapping
|
| |
|
| |
- If your package introduces build time circular dependencies, you should use this macro to bootstrap your package:
|
| |
+ If your package has build time circular dependencies, you will have to determine how to build one of the packages in isolation, possibly with degraded features in order to use it to build the other package in full. Then you rebuild the package with degraded features. You should use this process to bootstrap your package:
|
| |
|
| |
- ....
|
| |
- # When we are bootstrapping, we drop some dependencies, and/or build time tests.
|
| |
- %bcond_with bootstrap
|
| |
+ 1. Determine which package will be bootstrapped. Write a spec file for it that sets up what is required to get the package to build as a bootstrap (i.e. without relying on the other package). Also figure out what is required to build your package once the other package is available. See the next section for how to handle situations where the changes are needed. At a minimum you need to do this for your BuildRequires.
|
| |
|
| |
- [...]
|
| |
+ 2. Set the macro `%bcond_without bootstrap` at the top of your spec file. Now submit your package for review per the normal process. This logic reads backwards, to better understand it, read about xref:ConditionalBuilds.adoc[Conditional Builds].
|
| |
|
| |
- %if %{without bootstrap}
|
| |
- # dependencies for %%check
|
| |
- BuildRequires: foo
|
| |
- %endif
|
| |
+ 3. Once your package is approved and you have a repository, build your package with the above macro set.
|
| |
|
| |
- [...]
|
| |
+ 4. Once the other package is approved and built. You can rebuild your bootstrapped package. Do this by changing the macro you set above to `%bcond_with bootstrap` You do not need to bump the spec in F30 and beyond (see below).
|
| |
|
| |
- %if %{without bootstrap}
|
| |
- %check
|
| |
- make check
|
| |
- %endif
|
| |
- ....
|
| |
+ Please note that usage of pre-built binaries in bootstrap still needs an exception from the Packaging Committee as stated in <<General Exception Policy>>.
|
| |
|
| |
TIP: Since Fedora 30,
|
| |
as a nice side-effect,
|
| |
@@ -1602,6 +1593,26 @@
|
| |
by specifying `+%global __bootstrap %{nil}+`
|
| |
in your spec file.
|
| |
|
| |
+ === Making changes to a package based on whether it is a bootstrap or final build
|
| |
+
|
| |
+ In the examples, below `%if %{without bootstrap}` evaluates to TRUE if you set `%bcond_with bootstrap` and FALSE if you set `%bcond_without bootstrap`.
|
| |
+
|
| |
+ ....
|
| |
+ # When we are bootstrapping, we drop some dependencies, and/or build time tests.
|
| |
+
|
| |
+ %if %{without bootstrap}
|
| |
+ # dependencies for %%check
|
| |
+ BuildRequires: foo
|
| |
+ %endif
|
| |
+
|
| |
+ [...]
|
| |
+
|
| |
+ %if %{without bootstrap}
|
| |
+ %check
|
| |
+ make check
|
| |
+ %endif
|
| |
+ ....
|
| |
+
|
| |
If your package explicitly `+Provides:+` some functionality that is missing when bootstrapped, then that `+Provides:+` should look like:
|
| |
|
| |
....
|
| |
@@ -1610,8 +1621,6 @@
|
| |
%endif
|
| |
....
|
| |
|
| |
- Please note that usage of pre-built binaries in bootstrap still needs an exception from the Packaging Committee as stated in <<General Exception Policy>>.
|
| |
-
|
| |
== System cryptographic policies
|
| |
|
| |
Applications which make use the SSL or TLS cryptographic protocols MUST follow xref:CryptoPolicies.adoc[Crypto Policies].
|
| |
Add additional documentation for actually doing a bootstrap build and explain Conditional Build logic.