[Rpm-maint] [PATCH] forbid #%define

[Panu Matilainen]

On Fri, 6 Jun 2008, Pixel wrote:

> Panu Matilainen <pmatilai at redhat.com> writes:
>
>> A very straightforward and simple rule would be "if the first
>> character of the text to process starts is "#", braces are required to perform
>> macro expansion"
>
> i'd rather not introduce such a difference between %foo and %{foo}
> just for the sake of comments. Too surprising IMO.

I'm not saying it's necessarily "the right thing", but is it really more 
surprising than #-commenting not honored in specs which started this 
thread? :) Remember, the only thing the patch affects is macros on 
commented lines and nothing else. Conceptually that's not entirely unlike 
shell ${foo} syntax for ensuring expansion when otherwise it might not 
happen.

A more to the point approach would only enable such "comment mode" in spec 
context, leaving the rest of the macro system entirely untouched. Not that 
it probably matters anything, when loading macro files #-commented lines 
are honored (which just helps to make one think they might be honored in 
specs too)

> i'd say the more important is that spec editors should be adapted to
> rpm's behaviour. currently "#%define ..." is displayed as comments in
> vim/emacs. One way to fix would be to only fix the vim/emacs mode.

Teaching editors about it obviously wouldn't hurt anything, no matter 
which way this goes.

> instead of %foo vs %{foo}, we could do something like:
>
> %build
> cat << EOF > example.conf
> # To enable feature foo, uncomment the following:
> #[myplugin]
> %{expand:#pluginpath = %{_libdir}/%{name}/myplugin.so}
> EOF
>
> a bit ugly, but quite clear...

That's one approach yes, ugliness is in the eye of the beholder...

IMO the real problem in this whole thing is the horrible inconsistency in 
comment handling. %patch and %setup are "macros" yet they can be 
commented out with #. %build and such are section markers despite looking 
similar to macros, and can be commented out with #. %doc, %config etc are 
other special builtin operations and honor # commenting. BUT you can 
override any of these builtins in your macro configuration (bad idea but 
possible) and suddenly they behave completely differently without *any* 
indication why.

If macros were the only thing starting with '%' I doubt this whole problem 
would exist. Changing that in any way would break everything in existence, 
so it's hardly an option (apart from entirely new spec syntax). Now, we 
could make %patch and friends to behave the same as any regular macro in 
the name of consistency, but people would be screaming bloody murder if we 
%patch lines could no longer be commented out with # ;)

Changing how/when macros are expanded in comments is just the path of by 
far least resistance and breakage while making the common case behave more 
as one would expect, however it's implemented in practise. The blatantly 
obvious way would be to treat line beginning with # as a comment and NEVER 
do macro expansion on it. Like your example above shows, that wouldn't 
prevent creating comments with macros expanded.

 	- Panu -