[haiku-development] Re: Package-builders-build-off 2015
- From: "Alexander von Gluck IV" <kallisti5@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 29 Nov 2015 16:31:51 +0000
November 29 2015 6:59 AM, "Michael Lotz" <mmlr@xxxxxxxx> wrote:
On 29.11.2015 13:19, Adrien Destugues wrote:
On Sun, Nov 29, 2015 at 12:45:16PM +0100, Michael Lotz wrote:
How are circular dependencies to be handled? Waddlesplash's Kitchen
approach is: "I won't handle this, let's mark the packages as broken"
which means it can't be used to build OpenJDK, nor any of the core
components which the Haiku package depends on (gcc, binutils, libz,
freetype, etc). These are the packages I'm most concerned with, as
everything else could be handled by 3rd-parties.
Circular dependencies are handled the same as any other dependencies: They
need to be provided.
That means if OpenJDK requires a previous version of OpenJDK to build a new
one, such a previous
version needs to be provided in the packages directory. How this previous
version is generated is
not relevant. As there already are such packages available, these would be
seeded into the build
master environment and picked up as such (the same way the externally built
haiku.hpkg is used). In
the bootstrap case that means that corresponding packages would need to be
produced by cross
compiling them.
Since the system is built within HaikuPorter and HaikuPorter already
understands and uses the
present packages as part of its dependency resolution, this case isn't really
any different from a
normal build.
Haikeuken is the opposite of all of this.. i'm leaving all the logic to
haikuporter. The master server
sends down a random package that needs built, and the client issues the
matching haikuporter command to build it.
From a job orchestration standpoint, We issue a new random recipe / version to
each builder that we don't have
a latest revision package for in our master repositories, and continue to issue
the same recipe / version until the builder reports a success or failure.
(TODO: The builder will then attempt to post the resulting hpkg assets via http
until successful)
mmlr, what orchestrates what gets built on which nodes in your system? I
understand what you're looking to do (and it definitely sounds like the overall
best direction) but don't completely understand how you schedule / plan package
builds across multiple builders.
One thing i've learned is very few recipes in our repos build... there's always
some random failures that prevent proper builds (beyond circular dependencies).
I'm seeing around 1 out of every 20 build.
(if you click through the builds and the reasons they fail, it is interesting
to see how many reasons exist..
http://64.92.32.142:3000/builds)
-- Alex
Other related posts:
