The {{{%{!?_with_bootstrap: %global bootstrap 1}}} was proposed to allow koji (and probably copr) to use this macro in the future. I can already use it with mock (if it is in {{{%{?_with_bootstrap: %global bootstrap 1}}} form).

But otherwise, you still need the {{{%global bootstrap 1}}} for the bootstrap build ATM.

We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-12/fpc.2015-03-12-17.00.txt):

• 509 Further bootstrapping guideline changes (geppetto, 17:23:18)

• LINK: https://fedorahosted.org/fpc/ticket/509 (geppetto, 17:23:22)
• ACTION: Seems that people do use --with/--without for bootstrapping
  … so we can't just get rid of it. A new policy to vote on that has a
  changable default and reacts to --with--without would be nice. Maybe
  bcond? (geppetto, 17:37:20)

I think I'm going to declare this done. No matter what you do, you'll have to edit something in the spec to force the mode you want for koji. FPC would welcome a proposal upon which we could vote, so feel free to reopen this ticket if you'd like to provide one.

@james @tibbs

https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping

Below part in the page, looks wrong or confusing me.
the _with_bootstrap's meaning is opposite.
I want someone to change part.

%{!?_with_bootstrap: %global bootstrap 1}

For example I want to control the _with_bootstrap variable by mock --define 'define _with_bootstrap 1' or mock (without --define).

• If _with_bootstrap is not set from outside, bootstrap is 1 (bootstrap is True/Enabled).
• if _with_bootstrap is set as 1 from outside, bootstrap is not declared (= value is empty. It's kind of 0. bootstrap is False/Disabled).

Also using the negative operator !? is more complicated to understand the sentence.

@vondruch 's suggestion is better.

%{?_with_bootstrap: %global bootstrap 1}

• If _with_bootstrap is set as 1 from outside, bootstrap is 1 (bootstrap is True/Enabled).
• if _with_bootstrap is not set from outside, bootstrap is not declared (= value is empty. It's kind of 0. bootstrap is False/Disabled).

Typo.

`mock --define 'define _with_bootstrap 1'

mock --define '%global _with_bootstrap 1'

Sorry again.
Above sample was wrong.

Let me show you correct example.
See man mock --define for detail.

Sample.

$ fedpkg co rubygem-actionpack
$ cd rubygem-actionpack

Insert dummy BuildRequires inside of the bootstrap if statement.

$ sed -i '28 a\BuildRequires: rubygem(dummy)' rubygem-actionpack.spec

The result is like this.

 %if ! 0%{?bootstrap}
+BuildRequires: rubygem(dummy)
 BuildRequires: rubygem(activemodel) = %{version}

$ fedpkg srpm

--define '%global _with_bootstrap 1' is failed because of dummy BuildRequires.

$ mock -r fedora-rawhide-x86_64 --define '%global _with_bootstrap 1' *.src.rpm
...
No matching package to install: 'rubygem(dummy)'
...
Not all dependencies satisfied
Error: Some packages could not be found.

--define '_with_bootstrap 1' is succeeded.
dummy BuildRequires is skipped.

$ mock -r fedora-rawhide-x86_64 --define '_with_bootstrap 1' *.src.rpm
...
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
Finish: run

jaruga Can you open a new ticket to change the bootstrapping guidelines? Also maybe speak to packagers using bootstrapping right now if they are happy to change to the opposite way of doing things?

@james I can open the ticket. But why is the process to speak to packagers (Maybe on devel ML?) is necessary? The decision maker is not you?
You are not confident that current document is wrong?

@james Could you tell me your process to make a decision?

Below process?
I suppose that is packaging commitee's responsibility.

1. Speaking to packagers about this on devel ML.
2. If majority of them are happy, we will change.
3. If majority of them are not happy, we do not change.

@james
The purpose of this ticket was always to get %{?_with_bootstrap: %global bootstrap 1} 1 but somehow it never happened, although this was closed. Of course I noticed, but I got tired by this.

Obviously since nobody else complained, it just means nobody is really using the gudelines, since they don't really make a sense.

These are the proposed changes:

https://fedoraproject.org/w/index.php?title=User:Vondruch/Bootsrap_guidelines&diff=492334&oldid=492333

Going to create new ticket ...

Opened #684

Thanks to create new page! @vondruch

Few general comments:

1) 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.

2) 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

3)

%{?_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

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 this ticket should be IMO refused.