Bug 551366 - macro-in-%description check triggered even if percent characters are escaped
Summary: macro-in-%description check triggered even if percent characters are escaped
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rpmlint
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 567231 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-30 09:45 UTC by Paul Howarth
Modified: 2010-02-22 17:38 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-12-30 19:02:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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


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