Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1246746

Summary: Regression with recursive conditional macro
Product: Red Hat Enterprise Linux 7 Reporter: Remi Collet <fedora>
Component: rpmAssignee: Florian Festi <ffesti>
Status: CLOSED NOTABUG QA Contact: Karel Srot <ksrot>
Severity: medium Docs Contact:
Priority: high    
Version: 7.1CC: hhorak, lkardos, rcollet
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1323949 (view as bug list) Environment:
Last Closed: 2016-06-28 11:38:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1289025, 1295396, 1299750, 1313485    

Description Remi Collet 2015-07-25 11:58:13 UTC
Description of problem:
Recursively and conditionally defined macro behave differently in RHEL-6 (4.8) and RHEL-7 (4.11).
Fedora (version 4.12) behaves like RHEL-6, which seems correct)

Version-Release number of selected component (if applicable):
  rpm-build-4.11.1-25.el7

How reproducible:
  Always

Steps to Reproduce:
  Use in the spec 

  %if "%{?scl}" == "rh-php56"
  %global sub_prefix more-php56-
  %else
  %global sub_prefix %{?scl_prefix}
  %endif

  Name: %{?sub_prefix}php-pecl-%{pecl_name}

During SCL build, and %SCL = "php56"

Actual results:
  RHEL-6 and Fedora 21+
  Name is php56-php-pecl-name (correct)

  RHEL-7
  Name is php-pecl-name  (missing prefix)


Expected results:
  Name always php56-php-pecl-name


Additional info:
Example spec file : https://raw.githubusercontent.com/remicollet/remirepo/master/php/pecl/php-pecl-apfd/php-pecl-apfd.spec

Workaround: less conditionally defined macro (used in previous spec)
  %if 0%{?scl:1}
  %if "%{scl}" == "rh-php56"
  %global sub_prefix more-php56-
  %else
  %global sub_prefix %{scl_prefix}
  %endif
  %endif

Used to build https://www.softwarecollections.org/en/scls/remi/php56more/

Comment 3 Karel Srot 2016-04-05 07:18:37 UTC
According to my testing the problem is present also on RHEL-6, checked with rpm-4.8.0-37.el6. A have cloned the bug as bug 1323949.

Comment 4 Ľuboš Kardoš 2016-06-27 14:07:00 UTC
The comments in this bug are quite confusing. 

Remi wrote macros behaves differently between rhel-6 and rhel-7. Rhel-6 behaves correctly and rhel-7 behaves incorrectly. 

Karel wrote rhel-6 behaves incorrectly too. From that comment it seems that rhel-6 and rhel-7 behaves in the same way.

I think rhel-6 and rhel-7 behaves in the same way and they behaves correctly.

The problem is that the body of "%global" is expanded at definition time and not lazily like with "%define" but in the time when "%global sub_prefix %{?scl_prefix}" is defined the macro "scl_prefix" is not defined because the macro "%scl_package" which set the macro "scl_prefix" is used below "%global sub_prefix %{?scl_prefix}" definition.

Your workaround work because it uses %{scl_prefix} instead of %{?scl_prefix}, the macro "scl_prefix" is still not defined but the macro "sub_prefix" is set literally to "%{scl_prefix}" instead of "". And then when sub_prefix is called bellow calling the "%scl_package" macro it is expanded to "%{scl_prefix}" but now "scl_prefix" is already defined so the expansion continues recursively and %{scl_prefix} is expanded to value of the macro "scl_prefix".

You would have problems also with your workaround if you tried to use the macro "sub_prefix" before calling "%scl_package macro".

So advice is don't use a macro before it is defined. You use the macro "scl_prefix" in your spec before it is defined with calling the macro "scl_package". So simple solution is to move calling of the macro "scl_package" above the using of the macro "scl_prefix".

Comment 5 Karel Srot 2016-06-27 14:51:56 UTC
Hi Lubos,
as I am a bit lost in your explanation I can't say it is incorrect. :-)
OTOH, assuming that the current RHEL-6 and RHEL-7 behaviour is wrong, Fedora 23 works as expected.

Comment 7 Ľuboš Kardoš 2016-06-28 11:16:33 UTC
The problem is the "scl_prefix" macro is defined differently in rhel-7 and fedora. What I wrote in comment 4 applies for the macro "scl_prefix" in rhel-7.

The macro "scl_prefix" is defined in the package scl-utils-build, so this is a change in behaviour of the scl-utils-build package, nothing changed in rpm.

I am examining why this change was performed in the scl-utils-build package.

Comment 8 Ľuboš Kardoš 2016-06-28 11:38:20 UTC
The change in scl-utils-build was performed because of the bug 1057634. Side effect of that fix is that the code snippet described in this bug started to work. But this is not a regression, if the older version can't do something what the newer version can do that is not a regression.

You can ask for backporting this "feature" (more precise the side effect of some feature) to older version of scl-utils-build but there is no much sense in that as I already wrote it is enough to move calling of the "%scl_package" macro above your code snippet.

I am closing this, because this in not a bug in rpm at all, you can open a bug against scl-utils if you think that it is necessary.