Bug 2873

Summary: insufficient warnings on illegal macro names in macro file
Product: [Retired] Red Hat Linux Reporter: benedict
Component: rpmAssignee: Jay Turner <jturner>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: benedict, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-05-24 19:58:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description benedict 1999-05-17 13:17:12 UTC
Put the following illegal definitions in your macro file -
warnings will only be issued on some of them

%solaris2.x foobar
%solaris.x foobar
%solari.x foobar
%solar.x foobar
%sola.x foobar
%sol.x foobar
%so.x foobar
%s.x foobar

%irix6.x irix6.5
%hpux10.x  hpux10.20

%mu.x foobar
%mu.macro foobar

The warnings are

Macro %so has illegal name (%define)
Macro %s has illegal name (%define)
Macro %mu has illegal name (%define)
Macro %mu has illegal name (%define)

Comment 1 Jeff Johnson 1999-05-17 14:05:59 UTC
At the core of your request is how macro names should be parsed
in context. The rpm-2.5.x behavior was to parse non-space(s) until
next space, and according to that algorithm, you are expecting
error messages saying "%foo.bar" is an illegal name. (Note: there
is also the variant %{foo.bar} which is demarked by curly braces.)

In rpm 3.0, the parser accepts permitted characters in a name. That
will eventually permit constructs like
	%define	%sol	solaris2
	%sol2.5	=> solaris2.5
without the curly brace artifacts (e.g. %{sol2}.5.

Another implementation feature in rpm-3.0 is the ability to overload
pre-existing non-macro tokens (e.g. %prep) in a transparent manner
	%prep	%%prep
Note that each of the % in the above statement is different. First
there's the macro %, then the (obvious) escaping %, and finally the
1st character of the (non-macro!) token %prep. So, given the ability
to overload non-macro tokens with macros that might not be defined
when parsed, there is no way to generate an error message about
illegal macro names when the macro name is parsed.

Comment 2 Jeff Johnson 1999-05-24 19:56:59 UTC
*** Bug 2629 has been marked as a duplicate of this bug. ***

The following spec file snippet should echo twice when built
with buildos irix6.5 - in 3.0 it echos only once.


%define mymacro irix6.5

%ifos %{mymacro}
echo "Expansion of ifos %{mymacro} is OK"

%ifos iris6.5
echo "Expansion of ifos %{mymacro} is OK"

The output is

Executing: %prep
+ umask 022
+ cd /tmp/benedict/BUILD-test-3.0
+ echo Expansion of ifos irix6.5 is OK
Expansion of ifos irix6.5 is OK
+ exit 0

------- Additional Comments From jbj@redhat.com  05/14/99 14:35 -------
Macros are correctly expanded before processing %ifX statements.

Your example has a typo (iris6.5 vs. irix6.5), I can't tell which is
wrong without examining uname(2) strings on an SGI platform.

Please reopen this bug if there is still a problem.

------- Additional Comments From benedict@daimi.au.dk  05/17/99 05:53 -------
OK. Sorry about the typo.

------- Additional Comments From benedict@daimi.au.dk  05/17/99 09:30 -------
See Bug # 2873
    The original problem for me was that I did not get any warning
when I defined %irix6.x in a macro file - so I thought it was not
expanded when I used a conditional such as
    %ifos %{irix6.x}

Comment 3 Jeff Johnson 1999-05-24 19:58:59 UTC
Here's my typo:
        %define %sol2    solaris2
        %sol2.5 => solaris2.5