[OE-core] [PATCH] metadata-revs: provide more information

[Trevor Woerner]

On 03/13/16 16:53, Paul Eggleton wrote:
> On Sun, 13 Mar 2016 16:42:41 Trevor Woerner wrote:
>> That's the problem I'm trying to solve: how can I easily keep all the
>> information required to reproduce this build, exactly. The whole "two
>> meta's" thing was just a speed bump.
>
> Right, understood, and it does make sense. I'm convinced there is an
> underlying problem to fix that this just papers over though.

Okay, I think I see your point, and I agree. There is a layer clone 
problem that should be addressed.

But again, I think this is a speed bump.

My underlying point is that we're purposefully leaving out information 
that is vital to reproducible builds.


> This probably fits with what you said at OEDEM, which was that too often the
> system doesn't build properly out of the box for various boards. Have you had
> a chance to think about that problem further?

Oh yes, but I'm rather sure nobody's going to like my suggestion, which 
makes me hesitant to suggest it ;-)

It should be possible for me to hand you _one_ configuration file and 
from that you could reproduce my entire build in _one_ step by issuing 
_one_ command. If I can get something to build successfully for a given 
board, you should too. But currently that's not always the case.

bblayers.conf and local.conf should somehow be rolled into one and the 
build should have some sort of "repo tool"-like functionality built in.

I hand you this one configuration file, you run "bitbake some-or-other" 
and the build starts by going through the provided list of layers 
checking out the exact ones I have used and potentially checking them 
out at the exact revisions I've used. This means the layer list will 
have to specify from where the layer was found, which branch, what the 
HEAD was, etc. In other words, exactly the information I'm trying to 
capture at the end of any build today.

I really think this might help everyone.

Newbies would have a better out-of-box experience. Chances are they just 
bought some board and want to make a build for it. I think it is rare 
that someone stumbles onto The Yocto Project and is happy just doing 
builds for qemu. My belief is that people find The Yocto Project as a 
secondary event, the main event is they want to perform a build for the 
hardware that just arrived and is sitting on their desk. The generic 
documentation doesn't target their board specifically, so in addition to 
trying to understand this new build system, they also have to figure out 
how to get a layer, where to get it from, and how to add it to their 
build. I know that The Yocto Project does have BSPs for beaglebone, 
raspberry pi 2, generic x86(-64), edgerouter, and some ppc board... and 
if this newbie happens to have one of those, things might go better. But 
if they have some other board...

I think experienced developers would be helped too by the combined 
config+layer-full-details thing too. For example, developers would swap 
configs between each other more easily, and build artifacts could be 
kept for future reference which is very important in a production 
environment.

The current way of doing things purposely hides information, and this is 
bad.

bblayers only tells you that on a given day on a specific machine there 
was a layer at a specific location that was used for this build. If that 
layer is something that was pulled from somewhere else (and not, as Khem 
was mentioning, something that was done locally) then there is no 
mechanism anywhere that preserves this information. There's a gap; a gap 
in the information. On my machine there's a meta-browser layer, on 
github there are hundreds of meta-browser layers, bblayers just says I 
used something called meta-browser... but the link is missing which 
points to from where I got this layer.

If I wanted to be really devious I could clone my repositories with any 
weird old name I wanted. I could clone meta-browser and name it 
openembedded-core and clone openembedded-core and name it meta-trevor. 
My build would still work 100%, but good luck with that! :-D

The genie's out of the bottle. There already are hundreds of clones. 
There is no way to police it, there is no way to force people to use 
globally unique names. I don't know how you're going to fix something 
like that. I think the best thing is to recognize this is going to 
happen and take steps to mitigate the issue... such as specifying where 
layers are coming from both in the config (for external layers) and 
after the build to record what happened.

I don't want to embarrass anyone by giving names, and I certainly don't 
want to be seen as a troll :-( I've been playing around with a large 
number of boards for the last while and there are lots of issues that 
I've come across. I already mentioned my thoughts on the out-of-box 
experience for newbies who have just bought a board and now have to 
figure out how to successfully add a layer.

Another thing I come across is the following: given a company (ACME) who 
produces a bunch of boards (ACME-1, ACME-2, and ACME-3). The ACME-1 has 
CPU-1, ACME-2 has CPU-2, and ACME-3 has CPU-3. On github you'll find 
several meta-acme's and a couple meta-cpu's. Some of the meta-acme's 
will have support for one or more of the ACME-n boards, but not 
necessarily all of them, or you might find your board is supported by 
one of the meta-cpu repositories you've found. You'll even find one of 
those meta-acme's in the layerindex, but the developer of that 
particular layer only has 2 out of the 3 boards so that's all their 
layer supports. If you happen to have the one that's not in layerindex's 
meta-acme then you'll need to google and use some other meta-acme you've 
found yourself. When you ask the maintainers of the various meta-acme's 
to please get together and make sure the layerindex layer fully supports 
all the ACME board, sadly that doesn't happen. When you provide patches 
and pull requests to add the missing support, you're at the mercy of the 
maintainer, who is happy to refuse your contribution for all manner of 
reasons ;-)

Simply having a bblayers file that says meta-acme or meta-cpu isn't good 
enough. And hoping that we can all standardize on one layer... well, you 
know what they say about standards! :-D