Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add variable named scoping to rpm (#1150)
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. -- 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#issuecomment-707128466___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add variable named scoping to rpm (#1150)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add variable named scoping to rpm (#1150)
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 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#issuecomment-607215364___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add variable named scoping to rpm (#1150)
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 view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1150#issuecomment-607201957___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add variable named scoping to rpm (#1150)
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. -- 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#issuecomment-607130024___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add variable named scoping to rpm (#1150)
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: https://github.com/rpm-software-management/rpm/issues/1150#issuecomment-607125863___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add variable named scoping to rpm (#1150)
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
```rpm
%{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.
--
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#issuecomment-607120006___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
