Two deep flaws with macro expansions

[Jeff Johnson]

Proyvind was just asking abt integrating this (ancient iirc) Mandriva
patch:

http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-build-expand-field-for-single-token.patch?root=rpm5distro&view=log

The issue is exactly the same macro expansion flaw discussed here
        http://rpm5.org/community/rpm-devel/2077.html




the Mandriva patch, but both accomplish essentially the same goal,
adding one more expansion to a parameterized macro argument.

The patch is necessary for Mandriva because of the gawd awful way
they have chosen to automagically add Release: suffixes using a
parameterized macro.

Sure the patch "works" and is harmless (rpmExpand is little more
than strdup(3) on weak steroids).

But the extremely complex design issue however is
        Exactly where (and how many times) are tokens from spec files
        expanded?

If little spot fixes are poked into rpmbuild code, then documenting the
number of % escapes necessary to delay/disable macro expansion
will rapidly get out of hand. Note that there are already several forms
of delayed macro expansion permitted in rpm-5.0, and spot fixes
"because it looks like the right place" have profound consequences
for the number of needed % escapes to reach the correct expansion point.


an alternative symbol table handler implementation, from lua, from syck,

when the time comes without too much pain.

OTOH, if there are lots of hand-crafted extra expansion hacks, then RPM

forevermore.

The other flaw with macro expansion has to do with
        %global
versus
        %define

de facto usage of %define's in spec files.

There are no easy answers to either of these flaws.

But I can/will attempt a correctly engineered fix if requested. But the


hth

73 de Jeff
        

Namely that arguments passed to parametrized macros are not expanded before passing. OpenPKG is using %{expand: ...}, and that is a lot closer to Doing the Right Thing than If macro expansion purity (if you will) can be preserved, then substituting from XML, from Augeas, it really doesn't matter much, can be accomplished is stuck with the existing macros (and the existing rpmbuild implementation) usage. The flaw most definitely exists, but the cure will break almost every fix will need to be coordinated, ans the coordination is unlikely to happen afaict.

smime.p7s
Description: S/MIME cryptographic signature