Bug 551366

Summary:	macro-in-%description check triggered even if percent characters are escaped
Product:	[Fedora] Fedora	Reporter:	Paul Howarth <paul>
Component:	rpmlint	Assignee:	Ville Skyttä <ville.skytta>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	manuel.wolfshant, rjones, tmz, ville.skytta
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-12-30 19:02:32 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 Paul Howarth 2009-12-30 09:45:52 UTC

Description of problem:
The macro-in-%description check complains about percent characters in the %description text even if they are escaped (i.e. %%).

Version-Release number of selected component (if applicable):
0.91-1.fc12

How reproducible:
Every time.

Steps to Reproduce:
Run rpmlint on the perl-Regexp-Common SRPM, which has this %description:

By default, this module exports a single hash (`%%RE') that stores or generates
commonly needed regular expressions. Patterns currently provided include:

 * balanced parentheses and brackets
 * delimited text (with escapes)
 * integers and floating-point numbers in any base (up to 36)
 * comments in 44 languages
 * offensive language
 * lists of any pattern
 * IPv4 addresses
 * URIs
 * Zip codes

  
Actual results:
perl-Regexp-Common.src: W: macro-in-%description %RE

Expected results:
No errors or warnings.

Comment 1 Ville Skyttä 2009-12-30 19:02:32 UTC

This is not a bug - the only way to detect possibly misspelled (== unexpanded) macros in values read from rpm headers is to check for existence of % in their contents (this check operates on rpm headers, not specfiles).  This does result in false positives every now and then, that's why the message is a warning and not an error.  See "rpmlint -I macro-in-%description".

By the way, I'm not sure which perl-Regexp-Common SRPM you're referring to; none of the perl-Regexp-Common.spec files in Fedora CVS's branches have that description, they have just "Regexp::Common - Provide commonly requested regular expressions".

Comment 2 Paul Howarth 2009-12-30 21:00:22 UTC

(In reply to comment #1)
> This is not a bug - the only way to detect possibly misspelled (== unexpanded)
> macros in values read from rpm headers is to check for existence of % in their
> contents (this check operates on rpm headers, not specfiles).  This does result
> in false positives every now and then, that's why the message is a warning and
> not an error.  See "rpmlint -I macro-in-%description".

Ah yes, so I see. I'm sure the macro-in-%changelog test doesn't flag escaped percent signs so I was expecting similar behaviour for %description.

> By the way, I'm not sure which perl-Regexp-Common SRPM you're referring to;
> none of the perl-Regexp-Common.spec files in Fedora CVS's branches have that
> description, they have just "Regexp::Common - Provide commonly requested
> regular expressions".  

Hmm, right again. I must have been looking at my local package and thinking it was the Fedora one. Sorry for the noise.

Comment 3 Ville Skyttä 2010-01-05 21:33:25 UTC

(In reply to comment #2)

> Ah yes, so I see. I'm sure the macro-in-%changelog test doesn't flag escaped
> percent signs so I was expecting similar behaviour for %description.

You're right, and that's actually not an unfair expectation on first sight.  But the difference in treatment is intentional, see also the "rpmlint -I macro-in-%changelog" explanation and compare it to the "macro-in-%description" one.  In a nutshell, we basically do not want (unescaped) macros in %changelog at all, but they may very well be desirable in %description and other tags where the "history rewrite" problem does not exist.

Comment 4 Ville Skyttä 2010-02-22 17:38:39 UTC

*** Bug 567231 has been marked as a duplicate of this bug. ***