RFE: add variable named scoping to rpm

[nim-nim]

Right now a lot of things need special tags in rpm just because they have a specific (usual subpackage) scope, and can be declared in multiple scopes

Please add a generic construct to specify the scope of a set of variable, so those special Tag constructs can be ultimately replaced by easy to manipulate bog standard rpm variables

IE something like

%{scope(name):
# every variable get or set within this scope applies to the scope only
# the same variable may exist with the same name in a different scope
}

scopes should nest: setting a variable sets it for the inner scope, reading a variable cascades from the inner to the outer scope, till it finds a value for the variable name

[pmatilai]

We had this up to rpm 4.14 (all macros being local to the surrounding %{} scope), and the only thing it did was create endless confusion. Okay, buggy implementation didn't help, but there's no way we're going back to that mess. Remember the "%define is evil, everybody must use %global" touting in Fedora? That's where it comes from:
%{?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}

I have been entertaining a voluntary local scope for macros though, quite simply %local as opposed to %global. This would be more in spirit of keep simple things simple and complicated things possible.

[pmatilai]

Also, note that even in >= 4.14, macros (not variables) do have a scope: inside parametric macros, all %defines are local.

[nim-nim]

Thanks for the feedback! It makes me realise, that I forgot to emphasise things that were obvious to me (as a packager).

A scope needs an explicit name/anchor to be useful packaging side. It’s not a local vs global thing, it’s a “I do build things for context X now” and an later “I do checks for the same context X”, etc. Because a spec is not structured by subpackages, it is structured by phases, so at each phase you need to load and work with the same variables. Without an anchor to load the correct set of variables, you will make mistakes and things will fail (badly).

With a named scope thing you could do things like

%{scope(sourceA):
%global source sourceA.tar.gz
%global patch1 xxx.patch
%global patch2 yyy.patch
%global topdir foobar-32
}

%{scope(sourceB):
%global source sourceB.tar.gz
%global patch1 aaa.patch
%global patch2 bbb.patch
}

…

%prep
%{scope(sourceA):
%autosetup
}
%{scope(sourceB):
%autosetup
}

And each autosetup call only sees the set of variables corresponding to its own scope, and things just work without needing to find unique variable names and trying to pass them to %autosetup without mistakes.

It could also enable things like

%{scope(subpackage1):
%global name %{scope}
%global version ....
%global summary ....
%global description ....
}

%{scope(subpackage2):
%global name %{scope}
%global version ....
%global summary ....
%global description ....

%global filelist %{scope}.lst
}

…

%install
%{scope(subpackage2):
#do things for subpackage2, with all the associated variables available
… >> %{filelist}
}

...
%{scope(subpackage2):
%files -f %{filelist}
}

So, a very basic need, that is kludged today via -n flags, special Tags, an repeated argument passing at all steps of the spec.

Of course that makes the whole %global verb awkward. More automation means more variables, so maybe it‘s time to simplify variable declaration syntax in rpm.

[pmatilai]

Oh. I'm afraid this falls into the ponies department, at least in the realm of the existing spec machinery.

[nim-nim]

Well, if it existed I would not request it :)

It is part of adapting rpm to today’s software projects, that require more subpackaging and more subpackaging context than traditional make install things. Dev tools get more parametric, handling the result requires heavier variable passing.

[pmatilai]

The point is, this resembles #573 more than just a little, and is in the ponies department for the same reason: it's not possible to retrofit sanity and order into the existing spec tangle.

[nim-nim]

Even you you do not touch the existing spec tangle, we need to produce new spec tangles all the time, so what can rpm do to make the new spec tangles more sane? State of upstream projects is not frozen, tooling needs to grow like the projects it processes.

[pmatilai]

Coming across this again - nope. Understanding what happens where and when across the boundary between macros and build scriptlets is hard enough as it is, adding namespaces and scopes would only make it so much worse.

Judging by the examples given, the idea is to better support multiple different projects from a single spec.
The basic rpm design is that a single spec represents a single software project, although that content can be divided across sub-packages for various well-known reasons. I believe that is a sane and sound principle, and we shouldn't add features to the contrary.