X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 45D815C4F4F for ; Fri, 27 Apr 2018 16:30:16 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 0D65F9E3068 for ; Fri, 27 Apr 2018 16:30:16 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (67.63.200.37.customer.cdi.no [37.200.63.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 8CF619E00FA for ; Fri, 27 Apr 2018 16:30:15 +0000 (GMT) Date: Fri, 27 Apr 2018 18:30:10 +0200 From: Natanael Copa To: Alpine Development Subject: [alpine-devel] bootstrapping abuild and repositories Message-ID: <20180427183010.4514d397@ncopa-desktop.copa.dup.pw> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 ---