[haiku-development] Re: Package Building and Beta1
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 29 Jul 2017 12:22:28 +0200
On 28.07.2017 23:28, waddlesplash wrote:
On Fri, Jul 28, 2017 at 4:01 PM, Michael Lotz <mmlr@xxxxxxxx> wrote:
The Kitchen is reinventing the recipe and dependency logic already present
in HaikuPorter, with different code and, at least for recipe parsing, a
different approach. It does recipe parsing on its own and has a hardcoded
list of recipe parts it expects and can handle.
Yes, this is true; however, I've not had massive issues with the
parser. Sure, edge cases, etc. etc.
To me this just sounds like "there's a race condition, but we're not
going to fix it because it will only occur rarely". This wouldn't be
acceptable in Haiku code, so why should it be in its infrastructure?
Every time this happens it will require effort to figure out if the
problem is within the tool and effort by someone familiar with the tool
code to fix it. Considering the fact that most of our developers seem to
be unfamiliar with Node.js, this may not be such an insignificant
bottleneck.
This is "fragile" at the
very least, because it allows for situations where a recipe can be built
fine by HaikuPorter on its own, but will fail (or worse, produce subtly
different results)
Huh? In what case would it produce subtly different results? At the
end of the day, packages are still built with HaikuPorter -- so if
HaikuPorter builds a package differently, that's not it's fault.
It determines the dependencies based on the recipe and provides them to
the builder. If this comes to a different conclusion than what
HaikuPorter would have come up with, it may fail or produce a different
package. The fail case is just annoying and unnecessary, the other may
lead to strange results or brokenness further down the line that
requires even more effort to figure out. Even if this only happens very
rarely, contrasted to "it just can't happen", this is still a
unnecessary disadvantage to live with.
Yes; I don't parse all of Bash syntax, so naturally there will be a
small handful of special cases. However, that only means that recipes
will fail to be scheduled; not that it'll create "subtly wrong"
packages.
How can you predict what future recipes will look like? Maybe a new
mechanism is introduced because it makes recipes easier (sourcing a
common template, new built-in variables from HaikuPorter, etc.). Being
unable to take advantage of that due to a tool not automatically
supporting it, or having to wait for the tool to be updated to handle it
just seems needlessly constraining.
On the
dependency resolution side of things it has a hardcoded list of provides
that are assumed to be satisfied (see [2]), which IMO should just not be the
concern of the tool and not be needed.
This is how I chose to handle "base packages" -- my understanding is
that the Buildmaster expects the "base packages" to be available on
the server (i.e. you have to copy them there from an already working
install). I could very easily adopt that approach if everyone thought
that was the way to go -- but I've heard no major technical argument
that either way has some major flaw.
Well, the base packages would at least have to be a per-arch
configuration that can easily be updated IMO.
The advantage of using the actual packages is that you don't have to
touch the tool or its config when changing the base package set. Since
some of the packages are controlled "externally" (as in they don't come
from HaikuPorts but from Haiku) this seems more straight forward to me.
The argument "but you have to provide base packages, which is effort"
doesn't really count, as to have a stable build environment you have to
have these packages anyway (to provide them to builders).
It also fully depends on the package state of the builder. This can cause
issues due to packages not being in an expected state. As far as I know,
they aren't actively managed by the Kitchen either.
Huh? It expects only the "assume installed" packages are installed,
and I recently committed a change in which it runs pkgman to install
these on connect. Other than these pre-specified recipes, it downloads
all packages that the current build depends on from the server into
the "packages" directory of the haikuports tree. So, no, it does not
"fully" depend on the package state of the builder.
OK, I take back the "fully" and stand corrected that the Kitchen
provides at least partial management over the builder package set.
The hardcoded values still depend on a specific state (package names per
arch) that may easily change externally (maybe we switch to clang at
some point? or packages get split up, dropped or renamed). Having to
update the tool before being able to continue using the infrastructure
(or holding off on doing such changes) is again inflexible.
Also, when you only provide some of the packages and don't isolate from
the system packages on the builder, you may very well end up with
problems. Maybe of the packages you expect from the system has a
different version than expected and pulls in other dependencies, which
then causes the build to behave differently. Even with the chroot
separation, the system state bleeds through to some extent when you rely
on making system packages available inside the chroot.
This produces spurious
build failures that at least cost time to figure out (see example in [1]).
These outdated packages were some of the "assume installed". I can't
recall exactly how his builder got into such a state (but I believe I
introduced some safety checks to stop this mystery from occurring
again.) If the Kitchen adopted the "base packages on the server" model
I guess this would never happen again under any circumstances.
Yes, that kind of validates my point above.
On the other hand it appears to try and fulfil some dependencies by
installing a hardcoded list of packages manually (see [3]), which I again
find counter intuitive.
These are the minimum set of packages required so that the complete
ports-tree can be dependency-resolved without any circular
dependencies. Once again, I could solve it the Buildmaster way; I just
found this solution to make more sense in the long run.
How does splitting dependency information into the tool make more sense
in the long run? I can't come up with any advantage this might have,
only disadvantages.
If you count "effort for reworking the tool to be more like buildmaster"
as a disadvantage, then yeah, it seems easier, but only in the short term.
There are very few "ghost issues". Almost all the actual problems are
manifested in hard failures and are quite easy to debug. It's just
squashing flies, really -- a bit hard to find them, but once you do,
not hard to solve.
But aren't they prone to come up again and again with this setup?
Whenever someone finds a new clever way of making a recipe simpler or
something changes in the base package situation? Why not just use a tool
that doesn't expose itself to such issues in the first place (this could
also just mean making Kitchen use HaikuPorter to do the dependency
resolution, recipe parsing wouldn't really be necessary in the Kitchen
after that I guess). While developing the buildmaster I actually exposed
most of what you might need to pull this off.
The HaikuPorter buildmaster mode does not have any hardcoded assumptions
about dependencies. This means that it has to be bootstrapped with a working
set of packages and then satisfies everything from there. This means there
is an initial step of bootstrapping the buildmaster.
Yes, and I could easily make the Kitchen do the same, as I said.
Nobody had brought this up before, though, so of course I didn't
prioritize it.
I am pretty sure that I brought these exact points up when we discussed
this the last time.
So I guess out of all your concerns the only one that really stands is
the one about recipe parsing & dependency solving. Which hasn't proved
to be a very major problem yet. Most build failures we've been
encountering are legitimate and require recipe changes.
"Which hasn't proved to be a very major problem *yet*", that's my point,
why expose us to it becoming a major problem if it can be completely
avoided?
If you're truly "back" and wish to make this the reigning solution,
fine, I guess. But I must say it is EXTREMELY frustrating to have been
told in *2015* that this was what was going to happen, and then having
it not happen -- and now that the Kitchen is nearly ready for
primetime, to have the can of worms opened again.
Well, buildmaster tries very hard to be low maintenance by not having
assumptions so that it doesn't require changes when these assumptions
break. So being "back" isn't as pressing here. Also there are other
developers that have worked with or on the buildmaster side, which also
reduces the bus factor.
The frustration was all mine when the buildmaster setup produced
packages in early 2016 and I offered to set up the infrastructure but
was somehow just not allowed to, only to come back later to this same
situation again. It's not like the buildmaster came out of nowhere or
wasn't proven to actually work.
I want us to get B1 out this year, by hook or by crook. So I'm not
really bitter, and even if I was, I'd get over it. But please
understand that this is rather frustrating from just about any
standpoint, really.
I certainly understand the frustration. Still I don't agree with a "lets
do it this way because it's easier in the short term" approach. I've
always seen the Haiku project as striving for "the right way" even if it
has an initial overhead and takes longer. If it didn't, we probably
would've released a lot earlier after all.
By now I have been provided with access to vmpkg and have successfully
bootstrapped a gcc2h and a x86_64 buildmaster. I'm currently working on
adding my own builders to test the setup. Once everything is validated,
we can gladly add more builders from more people.
Regards,
Michael
Other related posts:
