Bug 551366 - macro-in-%description check triggered even if percent characters are escaped
macro-in-%description check triggered even if percent characters are escaped
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
: 567231 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-30 04:45 EST by Paul Howarth
Modified: 2010-02-22 12:38 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-30 14:02:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Howarth 2009-12-30 04:45:52 EST
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 14:02:32 EST
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 16:00:22 EST
(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 16:33:25 EST
(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 12:38:39 EST
*** Bug 567231 has been marked as a duplicate of this bug. ***

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