Bug 782381

+++ This bug was initially created as a clone of Bug #594672 +++

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.

--- Additional comment from jnovy on 2010-05-21 07:14:16 EDT ---

Fixed upstream. Thanks for reporting.

--- Additional comment from pmatilai on 2010-05-21 07:40:01 EDT ---

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

--- Additional comment from mbroz on 2010-05-21 07:46:20 EDT ---

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.

--- Additional comment from herrold on 2010-05-21 12:46:12 EDT ---

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

--- Additional comment from jnovy on 2010-05-21 14:52:09 EDT ---

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.

--- Additional comment from herrold on 2010-05-21 15:23:32 EDT ---

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

--- Additional comment from pmatilai on 2010-05-24 03:02:33 EDT ---

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

--- Additional comment from jnovy on 2010-05-24 03:40:58 EDT ---

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

--- Additional comment from pmatilai on 2011-01-19 08:46:46 EST ---

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


In previous bug, there is a problem that # is interpreted by shell and not rpm. The best would be to have some ability to comment out the whole line in rpm.
Some examples:
%configure whatever - rpm will expand configure macro and then run defined interpreter (shell default)
#%configure whatever- rpm will expand configure macro and then run defined interpreter (shell default). The interpreter knows what to do with #

My idea:
Use @ at beginning of line as comment for the whole line
@%configure whatever - rpm will determine the whole line as a comment and will not pass it to interpreter
- or -
@%configure whatever - rpm will not expand any macro on the line and will pass the line to interpreter

Anyway, # is ambiguous in rpm. Sometimes it is rpm comment and sometimes interpreted by shell (correct me if I'm wrong)?