[haiku-development] Re: Package Building and Beta1
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 27 Jul 2017 08:48:33 +0000
27 juillet 2017 10:27 "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> a écrit:
I don't think it's a good idea to use to completely different repository
sources for x86 and
x86_64. This doesn't just sound like a QA nightmare, it also produces a lot
more duplicated work
and effort.
But it is what we have already, so that work is already done.
We should of course make both architectures converge eventually, my point is
that we can do it after Beta1 to avoid further delays.
I think there are at least three ways in which a recipe can be broken:
1) It cannot be built.
2) It declares missing dependencies.
3) The resulting package does not work correctly or at all.
It's unfortunately more complex than that. Sometimes, a package is not broken
by itself, but it breaks other packages.
Some cases come to mind:
- Perl was updated to 5.22 in the release branch recently. The new Perl works
just fine, but they changed some things in regexp handling, and this result in
automake not working, so automake needed to be updated, too.
- Python was updated. The new package works fine, but some paths have changed,
so all python modules need to be rebuilt (using the same version of the sources)
There are several similar cases happening all the time. We have found ways to
limit some of these problems with proper version constraints in packages, but
we keep discovering new ones. So yes, a stable branch is needed where such
things should not happen without us knowning (and a plan for updating affected
packages).
To ease with getting testing populated, I would also have a repository built
from master. It would
be great if anyone with an account at HDS could request a package from master
to be included in
test automatically one day.
With the buildmaster triggered as a git hook, it would be possible to run it
each time someone submits a pull request to haikuports.
It could then rebuild the modified recipe, and make the artifact (the hpkg
files) available for testing.
I don't know if Kitchen could do a similar thing, and how we would feed it with
the changed recipe. Deos the REST interface allow for such things?
In the end, haikuports is like any piece of software: it's not and cannot be
always stable,
although it should always strive for it. Therefore we need at least a release
branch.
A possible alternative would be to have testing a complete branch, that
contains all packages, and
we have a separate list that contains the packages that should be forwarded
to the release branch.
This is not enough, because people sometime make changes to the testing branch
without moving to a new version of a package (only a new revision, so still
using the same recipe file). As a result, the files needed for the release may
not be in the testing branch anymore, and new files with the same name take
their place. This is why we need a full, separate release branch.
Instead of a single testing branch, it is also possible to use feature branches
(let's say, a perl-5.22 branch for handling that perl update), which gets
merged into the release branch after they got enough testing. This avoids a
problem where the testing branch accumulates too much changes and it becomes
difficult to identify the one change that caused a particular regression. When
things are split out into different branches, it is easier to do so.
--
Adrien.
Other related posts:
