[Rpm-ecosystem] Fwd: [Rpm-maint] Fixing macro scoping

[Vít Ondruch]

Dne 3.2.2017 v 13:14 Panu Matilainen napsal(a):
>
> Stunned silence on rpm-maint, forwarding to rpm-ecosystem in hopes of
> a larger and livelier audience...
>
>     - Panu -
>
> -------- Forwarded Message --------
> Subject: [Rpm-maint] Fixing macro scoping
> Date: Mon, 23 Jan 2017 12:30:21 +0200
> From: Panu Matilainen <pmatilai at laiskiainen.org>
> To: rpm-maint at lists.rpm.org <rpm-maint at lists.rpm.org>
>
>
> Consider the following snippet, originating from
> https://bugzilla.redhat.com/show_bug.cgi?id=552944:
>
> %{!?foo: %define foo bar}
> %define dofoo() true
> echo 1: %{foo}
> %dofoo
> echo 2: %{foo}
>
> I'd assume everybody agrees both %{foo}'s should evaluate to the same
> value, but that is not the case currently. Using a cli-variant of the
> above:
>
> [pmatilai at sopuli rpm]$ rpm --define 'dofoo() true' --eval '%{!?foo:
> %define foo bar}' --eval '%foo' --eval '%dofoo' --eval '%foo'
> warning: Macro %foo defined but not used within scope
>
> bar
> true
> %foo
>
> The flaw here is that rpm supposedly implements block level scoping
> for macros (so in the above example, "foo" would only exist in the
> {!?foo:...} block), but doesn't actually enforce that, unless a
> parametric macro is "called". Current rpm warns about it, but warnings
> or not this behavior doesn't make the slightest sense.
>
> The question is, what do you think %{foo} should evaluate to in this
> case?
>
> Fixing it to honor the strict "block scoping" concept is not hard, now
> that the scoping level is honored from Lua too (see
> https://github.com/rpm-software-management/rpm/commit/1767bc4fd82bfacee622e698f9f0ae42c02126fa).
> In this case the above reproducer would emit
>
> %foo
> true
> %foo

As far as I can tell, usage of %define is discouraged and I never really
understood why. But this example explains it and this should be the
right behavior IMO.

Vít