Bug 1260098 - [RFE] Support passing RPM macros to builds
[RFE] Support passing RPM macros to builds
Product: Copr
Classification: Community
Component: frontend (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Suchý
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2015-09-04 08:13 EDT by Radek Holy
Modified: 2015-10-05 22:14 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-04 10:47:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Radek Holy 2015-09-04 08:13:32 EDT
(I am not sure against which component should I file this)

In DNF, we use a %{?snapshot} macro in the spec file:
    Release: 1%{?snapshot}%{?dist}
in order to slightly modify the release number in case of building a snapshot. I find this approach far better than scripted modification of the spec file.

The disadvantage is that you need to pass the value to rpmbuild during building both the source package as well as the binary package (rpmbuild --define='snapshot .666' -bs dnf.spec). Unfortunately, Copr does not allow us to define this macro.

It would be nice to have this feature. I'm especially interested in using it in combination with the SRPM uploading feature and from python-copr. Let me know if I should create multiple RFEs.

BTW, if you find it better to provide a way to pass rpmbuild options, it's OK to me as well of course.
Comment 1 Miroslav Suchý 2015-09-04 08:43:59 EDT
We already have the capability to include some rpm in buildroot and they can include rpm macros. SCL is using that.
However this is inefficient for frequently changing macros.

I really believe that such feature should belong to tool, which construct SRPM. Copr use SRPM as input so IMO this does not belong to Copr. And it would be against reproducibility of builds as someone else would have hard time guessing how you created it.
And BTW Koji does not allow that as well.

I really recommend to put 
  %global snapshot foo
in your spec.
Tito is your friend. Or you can use -D to mock when constructing SRPM.
Comment 2 Radek Holy 2015-09-04 09:27:20 EDT
Did you try that? That's how I discovered the problem. And I also consulted it with the RPM guys.

You need to pass the macros in both situations: when building the SRPM as well as when building the RPM from the SRPM...

The difference between Copr and Koji is that you (can) build unofficial packages in Copr. And I believe that the macros can be recorded for the reproducibility purpose.

$ cat <<EOF >foo.spec
> Name: foo
> Version: 1
> Release: 1%{?snapshot}
> License: MIT
> Summary: foo
> %description
> foo
> %files
$ rpmbuild --define='snapshot .666' -bs foo.spec 
Wrote: /home/rholy/rpmbuild/SRPMS/foo-1-1.666.src.rpm
$ rpmbuild --rebuild ~/rpmbuild/SRPMS/foo-1-1.666.src.rpm 
Wrote: /home/rholy/rpmbuild/RPMS/x86_64/foo-1-1.x86_64.rpm
$ rpm -qpi ~/rpmbuild/RPMS/x86_64/foo-1-1.x86_64.rpm 
Name        : foo
Version     : 1
Release     : 1
Architecture: x86_64
Install Date: (not installed)
Group       : Unspecified
Size        : 0
License     : MIT
Signature   : (none)
Source RPM  : foo-1-1.src.rpm
Build Date  : Pá 4. září 2015, 15:23:47 CEST
Build Host  : dhcp-24-243.brq.redhat.com
Relocations : (not relocatable)
Summary     : foo
Description :

Sorry for reopening this but I believe that I've proved that your explanation is wrong. If I'm wrong, feel free to close it again but I would be glad for another reasoning.
Comment 3 Miroslav Suchý 2015-09-04 10:47:51 EDT
Yes, I tried that and I know how it works.

I still think that one time macros does not belong to build system. Neither Koji, nor OBS does that and I think that neither Copr should do that.

There are other tools which allows you easily modify the spec file. This is IMO far better way.

Note You need to log in before you can comment on or make changes to this bug.