[haiku-development] Re: Package buildbots
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 18 Oct 2016 08:28:27 +0000
18 octobre 2016 10:14 "Jessica Hamilton" <jessica.l.hamilton@xxxxxxxxx> a écrit:
On Tue, 18 Oct 2016 8:57 pm Adrien Destugues <pulkomandy@xxxxxxxxxxxxx> wrote:
18 octobre 2016 09:39 "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> a écrit:
Am 15/10/2016 um 10:59 schrieb Adrien Destugues:
I'm now at a point where the setup works reasonably well. It's time to
start plugging actual buildbots to it (so far I have used my two
development machines).
Great news!
The release branch with the recipes used:
https://github.com/pulkomandy/haikuports/tree/release
(I will push this to the haikuports repo if the haikuports team is ok
with that)
Well, that's where it ultimately belongs, doesn't it?
We will need policies on who can push to that branch and what the process
is. Since the build of
package repos will ultimately be triggered by pushing to that branch, we
need to be reasonably sure
that we don't push too broken things there.
Personally, I believe we need a split. Core packages that are essential for
Haiku itself should be
under the Haiku umbrella of hosting, and then apps and whatnot under
Haikuports.
And ideally, there should be mechanisms for third party repositories,
haikuports included, to
resolve dependencies to other repositories. This would also make automating
builds for third party
repositories easier when dependencies belong to others, and package versions
change, etc.
For the case we're dealing with, it would be something like this:
1) The buildmaster get an initial set of packages to work from. Currently, this
is haiku + all "core" dependencies and other things haikuporter can't build
itself (because circular dependencies, etc). All of this should come from the
"core" repo rather than haikuports.
2) The buildmaster uses this as a base and builds the dependency tree, to
schedule building packages in the right order
3) Packages are built!
So, the "core" repo currently isn't directly involved, but the packages from
there are manually given to the buildmaster. I expect that repo to be quite
stable with few changes for the beta/R1 branch (only security updates). For the
master/R2 branch, I have no idea how things will evolve.
But that's likely a lot of work, and shouldn't delay work on a release.
I'd be keen on a fork under Haiku and cherry picking commits. Even if we have
automated builds,
don't we still need committers to the haiku tree to publish changes anyway?
Actually, the simpler way to do this would be to keep the existing currently
called "haikuports" repo as it is currently managed (with git hooks from Haiku
repo). That repo should then be renamed, and coexist with the new haikuports
repo built using the buildbot. And, it should be stripped of all the packages
that are not needed to build Haiku.
Using the repo populated from the buildbot as a replacement of the current
system used to build Haiku needs more work (kallisti5 is looking into it).
There is also the problem of keeping Haiku sources in sync with specific
versions of the repo. A minimal change would be to keep the existing
infrastructure (package list, etc), but replace "jam upload-packages" with a
way to get the packages from the buildbot generated ones.
--
Adrien.
Other related posts:
