Actually I never like this approach, because I cannot check what build option or so is used for the binary rpm by checking the srpm afterwards. When I actually change such build option, I strongly suggest to make explicit change on srpm.

Actually I never like this approach, because I cannot check what build option or so is used for the binary rpm by checking the srpm afterwards.

I can agree with you.
But I do not know any other good ways to create the rspec module if we do not control rubygem-rspec-core.spec from outside by macro right now.

Is it so necessary or required that we can "check what build option or so is used for the binary rpm by checking the srpm afterwards"?

Hum, if we could edit the RPM spec file from module configure file, we would be happy.

I started to discuss to solve this situation here.
https://pagure.io/fm-orchestrator/issue/804

@mtasaka execute me.
If I change below code to comment out, are you fine to accept this PR?

%{?_with_bootstrap: %global bootstrap 1}

=>

#%%{?_with_bootstrap: %%global bootstrap 1}

I want to manage the fork version on my repository for enabled bootstrap.

Well, I may allow if binary rpm shows "this is bootstrapped" in some way, like below

Release: %{?preminorver:0.}%{fedorarel}%{?preminorver:%{rpmminorver}}%{?_with_bootstrap:.bootstrap}%{?dist}

even if %{?_with_bootstrap: %global bootstrap 1} exists - although I don't know this satisfies module build (Anyway if build option changes, I want to make Epoch-Version-Release changed, at least)

@mtasaka that's a great idea!

although I don't know this satisfies module build (Anyway if build option changes

I just remembered that some people tried to build bootstrapped SRPM with koji, replacing
from Release: ... %{?dist} to Release: .bs01%{?dist}. [1]
This is very similar with your suggested logic.

$ fedpkg --release master srpm

=> rubygem-rspec-core-3.7.0-2.fc28.src.rpm is created

$ mock -r fedora-rawhide-x86_64 --with bootstrap *.src.rpm

=> rubygem-rspec-core-3.7.0-2.bootstrap.fc28.noarch.rpm is created.

$ mock -r fedora-rawhide-x86_64 *.src.rpm

=> rubygem-rspec-core-3.7.0-2.fc28.noarch.rpm is created

Maybe I suppose the module build is checking order of the build by the dictionary order of the file name.

rubygem-rspec-core-3.7.0-2.bootstrap.fc28.noarch.rpm
rubygem-rspec-core-3.7.0-2.fc28.noarch.rpm

I want to make Epoch-Version-Release changed, at least)

I agree with this. Changing it is more safety.

[1] https://github.com/sclorg/rpm-list-builder/blob/master/rpmlb/builder/koji.py#L111

@mtasaka rebased adding %{?_with_bootstrap:.bootstrap}%{?dist}.
Are you fine for that?

@mtasaka just moment, @vondruch asking me in IRC personally not to apply this PR.

Just to clarify, I think that the ".bootstrap" string in the release is wonderful idea, but IMO it would be even better if the %dist macro was extended to support it directly, without modification of each and every spec which follows the bootstrapping guidelines.

I am asking here for %dist macro extended to support it directly.
https://pagure.io/fedora-release/pull-request/120

@mtasaka I rebased on current master branch.

I am asking here for %dist macro extended to support it directly.
https://pagure.io/fedora-release/pull-request/120

Finally %dist macro has included bootstrapping macro in it.

Build with bootstrap.

$ mock --with bootstrap *.rpm

%check section is skipped.

$ ls /var/lib/mock/fedora-rawhide-x86_64/result
build.log           rubygem-rspec-core-3.7.1-3.fc30~bootstrap.1.noarch.rpm
hw_info.log         rubygem-rspec-core-3.7.1-3.fc30~bootstrap.1.src.rpm
installed_pkgs.log  rubygem-rspec-core-doc-3.7.1-3.fc30~bootstrap.1.noarch.rpm

Build without bootstrap.

$ mock *.rpm

%check section is not skipped.

$ ls /var/lib/mock/fedora-rawhide-x86_64/result
build.log           rubygem-rspec-core-3.7.1-3.fc30.1.noarch.rpm
hw_info.log         rubygem-rspec-core-3.7.1-3.fc30.1.src.rpm
installed_pkgs.log  rubygem-rspec-core-doc-3.7.1-3.fc30.1.noarch.rpm
root.log            state.log

But concern is we have to update bootstrap document again.
(%bcond_without or %%bcond_with recommend?)
https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping

Anyway, I like this is merged for now.