~alpine/devel

[alpine-devel] bootstrapping abuild and repositories

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20180427183010.4514d397@ncopa-desktop.copa.dup.pw>
Sender timestamp
1524846610
DKIM signature
missing
Download raw message
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
---
Reply to thread Export thread (mbox)