On 2024-11-04 06:59, Richard Purdie via lists.openembedded.org wrote:
On Mon, 2024-09-09 at 12:36 +0200, Alexander Kanavin wrote:
On Fri, 23 Aug 2024 at 13:18, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
I think that if we implement BB_CONF_FRAGMENTS in bitbake itself,
we
will remove the need for the actual fragments file.
I struggle to understand what this means. Can you elaborate please?
What are option A and option B that seem to be compared here?
Sorry for the delay in replying, I've lost track of a few things. To
put this back in the original context of what I wrote:
1. There is a dedicated file for listing what fragments are enabled
in a build, something like build/conf/fragments.conf.
The prototype writes into local.conf, but writing into that with
tooling is undesirable. We already do it elsewhere, and it's all
hacks.
I think that if we implement BB_CONF_FRAGMENTS in bitbake itself, we
will remove the need for the actual fragments file. The main decision
at that point would be exactly where we include the fragments files.
I was saying that with dedicated fragment support in bitbake, the need
for the fragment *configuration* file (fragments.conf) would be
removed.
The decision we then have to make is where would bitbake add the
fragment files during the parsing process. Before or after anonymous
python fragments (probably before?). Before or after key expansion?
Those decisions are often really tricky and putting the include in the
metadata at a certain point (e.g. the lines in bitbake.conf) is one
easier way to make that clear. Despite that, I am leaning to a more
dedicated mechanism in bitbake than a fragments.conf file as it gives
us a more precise API in many ways.
I've been thinking about this as you've been discussing back and forth.
In the interest of starting with the dogfooding mentioned in a previous
email, is there a short list of easy config fragments we could put
together to start playing with?
One that I was thinking about would be a ptest fragment, but that might
require a little extra bitbake magic if we want to apply a per-recipe
ptest with it. This should work though, right?
DISTRO_FEATURES:append = " ptest"
EXTRA_IMAGE_FEATURES += "ptest-pkgs"
I saw a systemd config fragment mentioned. Package management?
I'm wondering if trying to build a series of config fragments that turns
core-image-minimal into core-image-full-cmdline might be a nice way to
sanity test and cover a lot of the bases already discussed.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2053):
https://lists.openembedded.org/g/openembedded-architecture/message/2053
Mute This Topic: https://lists.openembedded.org/mt/106611931/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
