#416 Proposal: Specifying macro definitions used for the build
Closed: Fixed 3 years ago by tkopecek. Opened 6 years ago by jaruga.

I want below features to specify macro definitions used for the build for Koji.

koji --define='_with_bootstrap 1'`
koji --with=bootstrap`

It is like rpmbuild --define='MACRO EXPR', mock --define="MACRO EXPR" and mock --with=OPTION.

The reason why I want is to build a package with bootstrapping mode [1].
People will use the bootstrapping mode to build the package that has circular dependency.

Of course people can build the package as manual bootstrapping mode editing the RPM spec file manually. For example inserting %global bootstrap 1 to the top of the spec file.

But in this bootstrapping document [1], we may want to show users easier way for Koji build of bootstrapping.

This proposal is from this discussion [2].

Thanks.

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
[2] https://pagure.io/packaging-committee/issue/684#comment-440569


You have to touch the spec file to bump the release anyway, right? Otherwise your bootstrap build may have the same NEVR as another build. So you'd might as well just change the bootstrap flag to 1 while you are editing the spec -- I'm not sure you'd gain anything :-)

Also wouldn't it be a problem if you allow packagers to produce a build that did not reflect what was in source control? (i.e. this way builds are less reproducible -- it would make it harder for secondary arches and other distros to rebuild our packages)

Release: %{?bootstrap:0.}1 or something along the lines might help resolve some of your concerns, right?

This is a tricky issue because it is assumed in Koji that the sources and the buildroot contents are all you should need to reproduce a build. This breaks that by adding a side input that affects the build process.

the sources and the buildroot contents are all you should need to reproduce a build.

I see that this is a policy of Koji.

If we respect the policy in Koji, we may have to type below commands for the bootstrapping before running Koji, instead of adding --define option to Koji.
But I am fine for that personally.

For example for rubygem-actionpack.spec.

Insert "%global bootstrap 1" to top of foo.spec file.

$ sed -i '1s/^/%global bootstrap 1\n/' rubygem-actionpack.spec

Bump the release number with --rightmost (-r) option.

$ rpmdev-bumpspec -c 'Enable bootstrap' -r rubygem-actionpack.spec

Seeing the difference after that.

$ git diff rubygem-actionpack.spec
diff --git a/rubygem-actionpack.spec b/rubygem-actionpack.spec
index d72107b..5fe88e1 100644
--- a/rubygem-actionpack.spec
+++ b/rubygem-actionpack.spec
@@ -1,3 +1,4 @@
+%global bootstrap 1
 # Generated from actionpack-1.13.5.gem by gem2rpm -*- rpm-spec -*-
 %global gem_name actionpack

@@ -7,7 +8,7 @@
 Name: rubygem-%{gem_name}
 Epoch: 1
 Version: 5.0.1
-Release: 2%{?dist}
+Release: 2%{?dist}.1
 Summary: Web-flow and rendering framework putting the VC in MVC (part of Rails)
 Group: Development/Languages
 License: MIT
@@ -93,6 +94,9 @@ popd
 %doc %{gem_instdir}/README.rdoc

 %changelog
+* Mon May 15 2017 Jun Aruga <jaruga@redhat.com> - 1:5.0.1-2.1
+- Enable bootstrap
+
 * Tue Jan 03 2017 Pavel Valena <pvalena@redhat.com> - 1:5.0.1-2
 - Enable tests.

@mikem It could be is as easy as add something like "bootstrap" package into the buildroot. The only content of the package is macros.bootstrap file which could define the macro.

Yes, this can be done by changing the buildroot contents. Folks have done it that way in the past. It does unfortunately mean a bit of work, and waiting for a repo regen.

If you are boostrapping, you need to wait for repo regen to propagate the first pass into buildroot anyway, so this is just minor inconvenience.

Koji remembers the mock config used for build right? So the second option could be to use special mock config with something like:

config_opts['macros']['%bootstrap'] = 1

Metadata Update from @tkopecek:
- Custom field Size adjusted to None
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata