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
Closed #1150.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1150#event-3866708604___
Rpm-maint mailing list
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.
--
You are receiving this because
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
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.
--
Oh. I'm afraid this falls into the ponies department, at least in the realm of
the existing spec machinery.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
