Bug 594672

Fixed upstream. Thanks for reporting.

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

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.

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

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.

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

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

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

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

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