Bug 1065463 - Commented %define still %defines
Summary: Commented %define still %defines
Keywords:
Status: CLOSED DUPLICATE of bug 594672
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 20
Hardware: i386
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-14 17:31 UTC by Hal Duston
Modified: 2014-02-27 09:55 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 143874
Environment:
Last Closed: 2014-02-27 09:55:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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 ***


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