Hi!
While working on the v3.8 build servers I came across the problem with
recursive dependencies for checkdepends. One example is flex and bison.
flex does no build without bison and bison needs flex for running
checks (it is in checkdepends).
abuild will by default run checks and thus by default pull in the
checkdepends. And the bootstrap failed due to this. I wonder how we
should deal with this, because this also affects general build order,
even when we don't boot strap things. (if we push bison and flex
updates in same git push, how do we detect which should be built first?)
We have the following options:
1) disable checks for builders (not a good option. we want run checks)
2) forbid circular dependencies with checkdepends. This means that we
disable checks that introduces circular dependencies.
3) handle circular dependencies manually. Manually break the circular
dependency by temporary build one of the packages without tests and
then rebuild it again with tests or cheat and manually add the
missing dependency (by enabling an external repository when needed)
4) build everything twice. Run one build without tests first and then
rebuild everything just built again but with tests enabled. This
approach means that we need to build every build batch twice (well,
everything that has tests enabled at least). This also raises the
question, what do you do if check fails? Lets say we build a
compiler without checks, and a bunch of apps built with this
compiler. Then on second run we re-build the compiler with checks
and the checks fails. In theory we should invalidate all the apps
built with the compiler too, regardless if those have checks or not.
So in theory, if second build (with tests) fails, every package
depending on the broken package should be invalidated.
5) something smart that does the correct thing effectively, without
rebuilding things unless absolutely necessary. Eg, automatically
detect which checkdepends that introduces circular dependencies, and
automatically break the circular dep by building it with tests
disabled and rebuild again with tests enabled once the dependencies
are satisfied, and handle failures correctly. I may need help how to
do this.
6) Something else?
I have been doing a combination of option 2 and 3 up til now but we
need a way to properly solve it. At least we need a plan who this
problem should be fixed in future.
Thoughts? Ideas?
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---