Red Hat Bugzilla – Bug 1478722
rpm: %{VERSION} versus %%{VERSION}
Last modified: 2017-08-07 03:30:41 EDT
Description of problem: For years, xemacs-packages-base.spec has included this definition at the top: %global xemver v=$(rpm -q --qf=%%{VERSION} xemacs-nox) ; case $v in 2*) echo $v ;; *) echo 0 ;; esac and this a little further on: Requires: xemacs(bin) >= %(%{xemver}) to capture the version of XEmacs used to compile the packages. It has worked. After the recent mass rebuild, xemacs-packages-base now has a dependency on xemacs(bin) >= 20160621; i.e., on its OWN version, not the version of the xemacs package used to build. This could only happen if %%{VERSION} in the macro was substituted with the Version: field of xemacs-packages-base. This shouldn't happen, since a double percent sign was used. If this is intentional, it is a backwards-incompatible change that should have been announced on fedora-devel-list. If this is not intentional, then I'm worried that other packages may have similarly broken dependencies after the mass rebuild. Version-Release number of selected component (if applicable): rpm-4.13.0.1-41.fc27 How reproducible: Always Steps to Reproduce: 1. Build xemacs-packages-base for F26 2. Build xemacs-packages-base for Rawhide 3. Compare the dependencies of the two builds Actual results: The F26 build properly depends on xemacs(bin) >= 21.5.34. The Rawhide build incorrectly depends on xemacs(bin) >= 20160621. Expected results: The package should depend on xemacs(bin) >= 21.5.34. Additional info:
I can't reproduce this locally.... $ fedpkg co xemacs-packages-base $ cd xemacs-packages-base $ fedpkg mockbuild $ rpm -qp --requires ./results_xemacs-packages-base/20160621/4.fc27/xemacs-packages-base-20160621-4.fc27.noarch.rpm | grep "xemacs(bin)" xemacs(bin) >= 21.5.34
This is because of https://github.com/rpm-software-management/rpm/commit/ccdb1aa5c675d917b1ba8d026c44fd95bab79e6c getting backported in the grand debuginfo backport set (to fix 1051407) You can work around it "%%%{VERSION}" as the query format (works for older rpm versions too) but note that executing rpm from within rpm (yes including build) has always been highly discouraged and will not work in various chroot situations.