Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 2873 - insufficient warnings on illegal macro names in macro file
insufficient warnings on illegal macro names in macro file
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Turner
: 2629 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 1999-05-17 09:17 EDT by benedict
Modified: 2015-01-07 18:37 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-05-24 15:58:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description benedict 1999-05-17 09:17:12 EDT
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 10:05:59 EDT
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 15:56:59 EDT
*** 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 15:58:59 EDT
Here's my typo:
        %define %sol2    solaris2
        %sol2.5 => solaris2.5

Note You need to log in before you can comment on or make changes to this bug.