Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 594672 - Macros in spec comments should not be evaluated
Summary: Macros in spec comments should not be evaluated
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 670553 1065463 (view as bug list)
Depends On:
Blocks: 782381
TreeView+ depends on / blocked
 
Reported: 2010-05-21 10:09 UTC by Milan Broz
Modified: 2015-08-09 22:30 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 782381 (view as bug list)
Environment:
Last Closed: 2010-05-21 11:14:16 UTC


Attachments (Terms of Use)
Patch committed upstream (deleted)
2010-05-21 18:52 UTC, Jindrich Novy
no flags Details | Diff

Description Milan Broz 2010-05-21 10:09:50 UTC
Description of problem:

If you try to comment some line in spec, the macros are still evaluated and it leads to strange situations, see:

Trying to check some new configure switch, commenting old line (here intentionally added some nonsense in comment):

%build                                                      
#%configure --grrrrrrrrrrrrr
%configure  --sbindir=%{_root_sbindir} --libdir=/%{_lib}

But this line is still interpreted!

# rpmbuild -ba x.spec
...
configure: error: unrecognized option: `--grrrrr'

Version-Release number of selected component (if applicable):
# rpm -q rpm-build rpm
rpm-build-4.8.0-14.fc14.x86_64
rpm-4.8.0-14.fc14.x86_64

I think if some part of spec is commented out, it should not be parsed at all.

Comment 1 Jindrich Novy 2010-05-21 11:14:16 UTC
Fixed upstream. Thanks for reporting.

Comment 2 Panu Matilainen 2010-05-21 11:40:01 UTC
Well... macros getting expanded even in comments and needing %-escaping is a long-standing documented behavior and not really a bug:
http://www.rpm.org/max-rpm-snapshot/ch-rpm-specref.html

Comment 3 Milan Broz 2010-05-21 11:46:20 UTC
Yes, I know that it is documented behaviour.
But I think it is wrong concept to expand macros in comments and is should be changed.

Comment 4 R P Herrold 2010-05-21 16:46:12 UTC
Jindrich Novy ... your comment 1 indicates 'Fixed upstream. Thanks for reporting'  

There are buildsystems and scripting which depend on this prior behaviour -- What did you do, and where may the commit be viewed?

-- Russ herrold

Comment 5 Jindrich Novy 2010-05-21 18:52:09 UTC
Created attachment 415747 [details]
Patch committed upstream

Russ, sorry for not being too verbose about this one. I'm attaching patch which is committed upstream.

I'm not sure I can imagine a real use case where an expansion of a macro is desired within a line which is commented out and that it is actually intentional. Could you please provide an example?

I believe a lot of people (including me) consider this feature ill-designed and annoying as it is more likely a source of real bugs within spec than anything useful, as Milan shows in his initial bug report.

Comment 6 R P Herrold 2010-05-21 19:23:32 UTC
Because of the absence of a extension mechanism in .spec files, arising from the absence of a grammar, PLD, JPackage, Zenoss, the Fedora project's R2spec generation tool's prior versions (I have not looked a the new version yet in depth to see if this persists), Dag and I each have overburdened comments  [ ^# ] with extensions for purposes such as carrying around versioned checksums through automated packaging generation systems.

The history of this is not material at this point; the effect of breaking installed base for at best cosmetic reasons by a 'quick commit' literally overnight from when an issue was filed is pretty casual at best for a tool nominally for a wider community than Red Hat 

When one wants to prevent expansions, or derung development when one wants to temporarily 'park' such a line for tracking down an isse, the convention, per Red Hat's prior RPM maintainers is to add the leading 'pound' and to 'double' the '%' which kills the expansion.  This is also used inside Red Hat beyond R2spec:

xorg-x11-server.spec:# The first step of %%prep is to check it out and switch to a "fedora" branch.

[herrold@centos-5 SPECS]$ grep "^#" *.spec | grep "\%" | wc
   2885   10026  179252
[herrold@centos-5 SPECS]$

This is a awful lot of potential breakage

Please revert the patch, and if it is really desired, let's discuss it on the mailing list instead

Thank you

-- Russ herrold

Comment 7 Panu Matilainen 2010-05-24 07:02:33 UTC
Yup, it's not quite as straightforward as one would like. The #%configure example seems like an obvious "aargh, wth did it expand that?" case (I too hate when that happens), but there are situations where the behavior could be legitimately used, for example to create content in here-documents. An artificial example:

%prep
cat << EOF > foo-compat.h
#if FOO_VERSION >= %{version}
#include <blah.h>
#else
#include <blech.h>
#endif
EOF

It's been discussed on rpm-maint before too, at least here: http://lists.rpm.org/pipermail/rpm-maint/2008-June/002102.html

Comment 8 Jindrich Novy 2010-05-24 07:40:58 UTC
(In reply to comment #7)
> Yup, it's not quite as straightforward as one would like. The #%configure
> example seems like an obvious "aargh, wth did it expand that?" case (I too hate
> when that happens), but there are situations where the behavior could be
> legitimately used, for example to create content in here-documents. An
> artificial example:
> 
> %prep
> cat << EOF > foo-compat.h
> #if FOO_VERSION >= %{version}
> #include <blah.h>
> #else
> #include <blech.h>
> #endif
> EOF
> 

Indeed, such constructs would not be possible otherwise. It is actually the first argument I see to allow macro evaluation within comments which makes perfect sense :)

The patch is now reverted.

Comment 9 Panu Matilainen 2011-01-19 13:46:46 UTC
*** Bug 670553 has been marked as a duplicate of this bug. ***

Comment 10 Panu Matilainen 2014-02-27 09:55:03 UTC
*** Bug 1065463 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.