#495 RFE: Support building SRPMs in target mock
Closed: Fixed by onosek. Opened by churchyard.

When using fedpkg srpm, fedpkg mockbuild and fedpkg build --srpm, the SRPM is created from spec on my system. This is a request for enhancement to allow building the SRPM in target mock (most likely via fedpkg srpm --mock, fedpkg mockbuild --srpm-mock and fedpkg build --srpm-mock or similar).

Mock already supports this:

$ mock -r epel-7-x86_64 --spec=python3-setuptools.spec --buildsrpm --sources=.
...
Wrote: /builddir/build/SRPMS/python3-setuptools-39.2.0-3.el7.src.rpm
Finish: rpmbuild -bs
Finish: buildsrpm
INFO: Done(python3-setuptools.spec) Config(epel-7-x86_64) 0 minutes 9 seconds
INFO: Results and/or logs in: /var/lib/mock/epel-7-x86_64/result

Rationale

Spec files often contain target specific constructs that fail to build or produce invalid results on non-target platforms. One of the reoccurring example is a common EPEL 7 Python 3 specfile pattern:

Name:           python3-setuptools
...
%package -n python%{python3_pkgversion}-setuptools

%{python3_pkgversion} is 36 on EPEL 7, so this is perfectly valid. But on Fedora, it is 3 and the SRPM cannot be created:

$ fedpkg --release epel7 srpm
error: line 54: %package -n python3-setuptools: package python3-setuptools already exists
error: query of specfile .../fedora-scm/python3-setuptools/python3-setuptools.spec failed, can't parse
Could not execute srpm: Could not get n-v-r-e from .../fedora-scm/python3-setuptools/python3-setuptools.spec

Thanks for considering. cc @lbalhar


Another example might be python-twisted-web which uses %python macro in its specfile in a way which is valid in RHEL 7 but not in the current Fedora. Therefore I am not able to build SRPM on my Fedora workstation when I work on this package.

See this Bugzilla as well: https://bugzilla.redhat.com/show_bug.cgi?id=1767576

I also opened a bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1906755) related to this request. IIUC, the spec file is being processed in the request machine and we could benefit from processing them in the target mock.

Commit e94dc065 fixes this issue

Thanks!

Metadata Update from @onosek:
- Issue set to the milestone: 1.64

Metadata
Related Pull Requests