[Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)
nim-nim
notifications at github.com
Mon Oct 29 18:24:37 UTC 2018
What a wonderful idea. You’re right. *BuildRequires* are the current pain point, but there's no reason the rest won’t want to be done after this problem is fixed.
However I think the way rpm syntax tries to pretend rpm and srpm are symetrical makes you miss the obvious. rpm and srpm are not symetrical. srpm-things are package-wide and need to be evaluated at specific points of the build process. rpm-things OTOH can all be evaluated at the end of the build process when rpm packages are assembled, but they are (sub-)package specific.
Therefore I don't feel the script syntax model is the right one. Something like `%files`, with a static manual list of elements, and an optional file of computed elements, will probably work better.
So how about something like this?
```specfile
# Declarative section. For syntax symmetry
# Static BuildRequires could be migrated here over time
# Anything needed in %prep or by the macros used before prep
%sourcedeps
BuildRequires: x
BuildRequires: y
# Script section
%prep
# Another declarative section. With an optional computed list and static declarations
%builddeps -f <computed list>
BuildRequires: z
# Script section
%build
[…]
# Declarative sections for the built packages
%files -f <computed list>
%doc xxx
%deps -f <computed list>
Requires: moo
Obsoletes: foo < %{version}-%{release}
%files devel -f <computed list>
%doc yyy
%deps devel -f <computed list>
Recommends: a_compiler
```
* that makes it clear what is srpm-specific and what is (sub)-package specific
* it makes it clear when each part is evaluated
* it allows mixing static and dynamic declarations freely
* it's symetrical with `%files` and won`t feel alien to existing packagers.
* it's extensible: you don’t need to invent new script names for every possible dep clause, you can add support for new clauses over time to the same section
And that opens the way to more syntax cleanups in the future, like straightening up of the headers that apply to the srpm and those who apply to the rpm (once upon a time Build* applied to the srpm and the rest to the rpm, but that has changed since, and the limit between those is not obvious nowadays as long as they are not in separate sections). Or merging `%files` and `%deps` in a new section. Or cleaning up Sources/Patches via a `%prepfiles` that applies to the srpm. There are lots of things that could be done at some point of the future.
Short-term, we only need to implement `%builddeps`.
--
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/104#issuecomment-434023402
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20181029/5a841c0e/attachment-0001.html>
More information about the Rpm-maint
mailing list