[haiku-development] Re: Handling ABI changes with packages buildbots
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 6 Oct 2017 00:45:03 +0200
On 30.09.2017 16:13, Adrien Destugues wrote:
However, this means packages doing notifications are now broken. I tried
to trigger a rebuild of the Vision package by bumping its REVISION,
however, it seems the package build bots and builmaster are still using
an old version of Haiku, so Vision was still built against the old ABI
and the new package still crashes on an up to date system.
Yes, the update process of the buildmaster is one of the items that I
started a discussion about that never concluded.
The simplest is to regularly update everything (builders and
buildmaster). With buildmaster the version of Haiku running on the
builder is somewhat independent of the version packages are built
against (as long as they are syscall compatible). The buildmaster
distributes the Haiku packages to the builders to be used in the chroot
the same way it does for other dependencies. Still, having them diverge
too much probably isn't a good idea.
What is the process to update the haiku packages on buildmaster? Do I
just ssh to there and drop newer haiku packages at the right place?
Yes, that would be the manual option. The place in this case would be
the initial-packages directories of the respective buildmaster instance:
/builds/buildmaster/master/x86_[gcc2|64]/haikuports/buildmaster/initial-packages
Any updated initial dependency packages should be updated there as well.
Should we automate that from the nightly builds of Haiku or something?
Possibly. The problem here is that all packages built after an update
will require at least that Haiku version. This would force people to
update their base Haiku just to get to a package that would technically
be perfectly compatible with their older Haiku. This is mostly a policy
decision IMO.
The buildmaster bootstrap process (not related to the Haiku bootstrap
process) currently builds a haiku-nightly.image and then uses the
downloaded and built HPKGs to seed its initial-packages.
An automated update process could easily reuse that mechanism, updating
the cloned Haiku repository, rebuilding the image and re-seeding the
initial-packages from it.
I have done the above update process manually now and updated the
initial-packages for both buildmaster instances. I will add a script to
HaikuPorter to automate these steps (analogous to the bootstrap script).
When to update, and how to decide what packages to rebuild as well as
how to trigger the builds (rebuild everything after such an update or
bump the revision of the individual recipes) is still up for debate.
Depending on the update granularity rebuilding everything could be
prohibitive. Seeing that the breaking changes are relatively rare, I'd
consider a manually triggered approach like with the time_t change.
I'd also favour not rebuilding everything needlessly, seeing that my two
builder instances are the only ones producing packages and the x86_gcc2
one has extremely slow IO.
Regards,
Michael
Other related posts: