> Contrarian examples are trivial to devise. Consider an autoconf based
> generated file that builds if (and only if) certain files are detected. None
> of those BuildRequires can be automated and generated during a spec file
> parse with a pipe/file redirection.
That's more or less the Go system right now, computing deps is just a special
compiler mode where it dumps what it will need instead of building the project
(it is slowly evolving as a separate command, but still, it will continue to
call Go compiler innards behind). So that depends what you call "build" if
"building" means calling the compiler yes that's building, my definition of
building is producing files.
I don't think it needs more than one phase at present though.
> Repopulating a buildroot with additional "dynamic" BuildRequires and
> restarting an rpm build either needs to teach rpm how to install additional
> packages as a side effect of parsing,
It only needs to teach rpm to:
- pass dynamic BRs requests to the buildsystem,
- bomb if the BuildSystem is unable to provide them (and in case of no build
system, bomb if the dynamic BRs are not already present).
- continue otherwise
There is not need to add BR provisioning logic to rpm itself, that has not been
its role for quite a long time.
>or needs to be handled by dep solvers that populate the build root (entirely
>out of scope for the current rpmbuild implementation) before rpmbuild is
>invoked.
I think everyone would prefer the current responsibility separation where rpm
does the parsing and building and the build system does the provisioning
> There is currently no known way other than "works" to verify that the
> BuildRequires passed to the depsolvers that populates the build system used.
You're over-engineering things. Builds can fail with static BR too, a requires
system has never promised builds *will* succeed, only that the material they
should need is present at build time.
> Only looping to test that the BuildRequires are sufficient.
That's why I proposed a two-command compute-BR/populate-BR system, that makes
incremental dynamic BR composition possible, and places the packager/language
integrator in command of when dynamic BR population is needed, and whether it
is needed once or several times
(everyone will understand that the populate-BR is expensive in build time, so
the packager's interest will be to batch as much compute-BRs as possible to
limit populate-BRs calls)
Of course you can make the looping implicit, force the packager to declare all
the compute-BR engines
(a project can include code in several languages) before a specific step in the
spec, and then at this step loop
- execution of all compute-BR
- populate-BR
till first step produces no dynamic BR not computed before.
That's a more brute-force approach. It will possibly be simpler to use by
packagers, at the expense of increased build times (because the compute-BR
logic will necessarily be simpler and more brutal too) and making some
use-cases like declaring the BRs needed by unit tests in %check impossible.
> Hence any attempt to automate BuilRequires MUST have a persistent incremental
> store from which the automagically generated BuildRequires can be retrieved
> on the final build.
"final" build is a murky concept when a project can include code in several
languages, and %checks can include many tests which are all small build units.
I'd rather have a system that either declares the end of %prep or %prep-br the
final limit after which no BR resolving occurs, or no rpm-enforced limit with
an explicit fetch-BR command that can occur in all spec sections that need new
BRs
Now as you astutely noted:
1. adding BRs is necessarily incremental (dynamic BR removal is too horrid to
contemplate and all the systems I know are additive, not substractive, at worst
the build commands know how to ignore stuff it doesn't need or want)
2. rpm needs to remember the result of the last compute-BR call to
- abort the loop when no new BRs are produced in case of implicit looping
- return a "you already asked this" error code from populate-BR if you go the
explicit call route
--
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-366426484
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
