@ffesti You're complicating things unecessary, rpm does not distinguish between
manual and dynamic provides, there's no need to distinguish between manual and
dynamic BuildRequires either
In a dynamic BuildRequires world, the spec still contains static BuildRequires
(sufficient to pull in the build root whatever is necessary to compute the
dynamic BuildRequires) and the packager executes at the end of %prep whatever
command or commands are appropriate to compute those BuildRequires
That allows the packager to "fix" the project state that serves as a base to
the computation, to massage the command output if needed, etc
All it needs is an rpm entry point that pipes a string or a string list into
the BuildRequires list during %prep, for mock or whatever to read the final
BuildRequires state at the end of %prep and complete the build root as needed
If you want maximum flexibility you can even forget about %prep or not %prep,
and do it with two spec verbs:
1. one verb that accepts piping new BuildRequires (one per line, without the
BuildRequires prefix) or alternatively as arguments
2. another verb that basically kicks the build system and tells it "add to the
build root all the BuildRequires not already present"
and let packagers define the best dynamic BR strategy over time. Adding BRs
just in time would simplify a lot of ifdefing in %build and %check for example:
just request the BRs in the optional section instead of trying to sync several
optional sections in different parts of the spec
--
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-364795706
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
