Re: [OE-core] [RFC PATCH] bitbake-layers: add layer repositories/revisions save and restore tooling (aka 'layer configuration')

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2022-07-05 at 10:34 +0200, Alexander Kanavin wrote:
> On Tue, 5 Jul 2022 at 05:09, Andre McCurdy <armccurdy@gmail.com> wrote:
> > My proposal would be to try to reuse Linux kconfig. Users know how to
> > run "make oldconfig", "make menuconfig", etc and I believe all key
> > distro / machine configuration along with which meta layers should be
> > enabled, which branch to use, etc can all be captured within a kconfig
> > .config file. The task at hand would then become writing a tool to
> > translate from a .config file to a set of distro, machine, local.conf
> > config files (and an image recipe?) + drive whichever tool will be
> > used to fetch meta layer git repos.
> 
> At this point, I have to remind everyone about our harsh reality.
> Which is having lots of core pieces without maintainers:
> https://git.yoctoproject.org/poky/tree/MAINTAINERS.md#n45
> 
> Let's focus on adding foundational pieces of layer and configuration
> management in a controlled, testable and tested manner for now. Which
> is what I am trying to do. I think discussing grandiose designs for
> things that try to please everybody is just a bit premature, honestly.

There is a time and a place for incremental improvement and also a time
and a place where we need to step back, look at the bigger
picture/problem and try and design for that.

It is no secret that I've been avoiding the layer setup issue, I know
it is a painful topic and will be hard to solve. I'm also acutely aware
that we can't ignore it for that much longer, we need to do something
about it.

The challenge with your approach is that it is bolted directly onto
bitbake-layers, which makes it not only OE-Core API but bitbake API
too. There is a standard such changes need to reach and I'm not
convinced that is doesn't tie our hands in future as is.

I suspect in reality, we could probably have the same functionality in
a separate script in OE-Core, maybe improving the APIs/library
functions from bitbake-layers if needed. That would lower the bar and
mean we could have something focused on eSDK needs rather than the
wider problem.

Of course that potentially misses an opportunity to potentially address
the wider issue. I did at least take the time (on a weekend) to write
down my thoughts, which wasn't particularly easy.

As for kconfig, I don't think we need another config file format. I
have proven that json can encapsulate all the complexities of the
configurations of the autobuilder and kas has also proven the same
think with yaml. Yes, the menus are nice but at some point users will
need to see our config files so I don't think its a much of a win as
people think, unless the entire project used it which it doesn't and is
unlikely to.

Cheers,

Richard