Bug 1065463

Summary: Commented %define still %defines
Product: [Fedora] Fedora Reporter: Hal Duston <hduston>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 20CC: ffesti, jzeleny, mjs, nobody+pnasrat, novyjindrich, packaging-team-maint, pknirsch, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 143874 Environment:
Last Closed: 2014-02-27 09:55:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hal Duston 2014-02-14 17:31:59 UTC
+++ This bug was initially created as a clone of Bug #143874 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
A %define directive on a comment line still %defines the symbol.  If
the commented line appears after a live %define directive, the
commented definition replaces the live one.

Commented lines should have no effect.

Version-Release number of selected component (if applicable):
rpm-4.3.2-21

How reproducible:
Always

Steps to Reproduce:
1. Install the attached foo.spec file in SOURCES.
2. rpmbuild -bp foo.spec
3.
    

Actual Results:  Output echoes "bazz" on screen.

Expected Results:  Output echoes "bar" on screen.

Additional info:

foo.spec file attached below.

Note the lines:

%define foo bar
# %define foo bazz

The latter %define overrides the former, even though it is commented out.

--- Additional comment from Matthew Saltzman on 2004-12-30 11:26:38 EST ---

Build this package (foo-0.0) with "rpmbuild -bp foo.spec".  The output echoes
"bazz" when it should echo "bar".

--- Additional comment from Paul Nasrat on 2004-12-30 11:29:32 EST ---

This is a known limitation of the spec parser, macros are expanded everywhere -
comments, changelog etc. Common packager approaches are to either add a % to
escape or replace the % with the #
eg:

#%%define foo bazz 

or 
#define foo bazz

--- Additional comment from Matthew Saltzman on 2004-12-30 11:55:51 EST ---

OK fine, but this needs to be documented in big red letters in places that
specfile authors are likely to see it (appropriate sections of the HOWTO and 
Maximum RPM, at least).  For anyone used to most common programming languages,
shell languages, makefile syntax, etc., this is totally unexpected behavior.

In the Maximum RPM snapshot
(http://www.rpm.org/max-rpm-snapshot/ch-rpm-inside.html#S1-RPM-INSIDE-COMMENTS)
the following appears:

Comments are a way to make RPM ignore a line in the spec file. The contents of a
comment line are entirely up to the person writing the spec file.

To create a comment, enter an octothorp (#) at the start of the line. Any text
following the comment character will be ignored by RPM. 

The same appears in Appendix E
(http://www.rpm.org/max-rpm-snapshot/ch-rpm-specref.html#S1-RPM-SPECREF-COMMENTS)

I have not encountered any reference to expansion of macros in comments anywhere
I've looked.

--- Additional comment from Paul Nasrat on 2004-12-30 12:01:45 EST ---

For speedy update patches against maximum rpm happily taken and the snapshot
will be updated. CVS details here, feel free to attach here or post to rpm-list:

http://rpm.org/cvs_help/



--- Additional comment from Matthew Saltzman on 2004-12-30 14:08:28 EST ---

OK Will post here or there when I have a chance to write the patches.

Comment 1 Hal Duston 2014-02-14 17:40:01 UTC
Re-opening this bug, 9 years later.  This may be a known limitation to the developers of rpm itself, but it is NOT a known limitation to anyone else.  If rpmbuild can be prevented from expanding macros (eg. %define) in false branch of %if clause, it ought to be able to be prevented from expanding macros in a comment line.

Comment 2 Panu Matilainen 2014-02-27 09:55:03 UTC
It's not a limitation, that macros are expanded everywhere intentional behavior for all I can tell. Clearly it breaks the principle of least surprise in specs, but there are packages and other systems that rely on the (documented even) behavior, we cant just go changing it either.

*** This bug has been marked as a duplicate of bug 594672 ***