Re: [bitbake-devel] [PATCH] toaster: Add recipe variables view

[Paolo Wattebled <paolo.wattebled@savoirfairelinux.com>]

Hi Richard,

Thanks for the feedback.

The 598 figure is the number of recipes in that build, not the number of
variables. Each recipe has its own build-specific snapshot, giving 19,756
variable and flag entries in total—around 33 per recipe on average.

Each snapshot contains the final resolved values specific to that recipe,
including changes from its .bb, matching .bbappend and included .inc files, as
well as flags such as PACKAGECONFIG[...]. Values inherited unchanged from
global configuration or classes are excluded, along with functions and inactive
overrides.

Screenshots of the linux-imx variables, bluez5 PACKAGECONFIG values and flags,
and variable counts in the recipes table are available here:

https://imgur.com/a/u20rf3O

Regarding history, the current implementation stores one resolved snapshot per
build. If build 1 resolves A to 1 and build 2 resolves it to 2, both builds
retain their respective values. It uses BitBake variable history for selection,
but does not persist the complete assignment and operation history.

To provide a little more context, this work supports vulnerability assessment
in VulnScout through its new MCP functionality.

Build metadata and resolved variables provide useful context for producing an
accurate assessment. For example, PACKAGECONFIG can help identify the features
enabled in a recipe and the resulting attack surface.

Our longer-term goal is to expose relevant recipe and global variables through
Toaster and MCP, together with selected layer configuration such as kernel
defconfigs. This should give an agent enough build-specific context to produce
a more informed vulnerability assessment. For more information on VulnScout:

https://github.com/savoirfairelinux/vulnscout

Thank you also for the encouragement regarding the Toaster use case. I will
prepare v2 as an incremental series, separating data collection, database
storage and the user interface.

Cheers,
Paolo


----- Original Message -----
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: "Paolo Wattebled" <paolo.wattebled@savoirfairelinux.com>
Cc: "bitbake-devel" <bitbake-devel@lists.openembedded.org>
Sent: Thursday, August 13, 2026 11:58:45 AM
Subject: Re: [bitbake-devel] [PATCH] toaster: Add recipe variables view

On Thu, 2026-08-13 at 11:31 -0400, Paolo Wattebled wrote:
> Thanks for raising this. I ran a quick comparison with and without the change.
> Toaster startup and recipe parsing were effectively unchanged (2m46.554s vs
> 2m46.835s). A cached imx-image-core build took 4m23.648s versus 4m07.387s,
> about 16 seconds slower. After vacuuming, both SQLite databases rounded to 74
> MiB, including 598 per-recipe variable snapshots. I understand that some of
> this data is stored twice. However, I only store variables changed by recipes
> or bbappends, and I compress them before saving them. In my test, this did not
> noticeably increase the database size.

This does raise a few more questions. I don't think you're covering all
the cases where variables change in recipes as *every* recipe will have
recipe specific values and 598 seems like a low number.

You appear to be only considering where overrides are used but
overrides aren't the only way variables can be changed as =+ and so on
are possible, or the value can just be overwritten.

I don't mind toaster reading out and storing the data but you may as
well just read the data, there is little point in changing the cache
structures to add/cache it?

It does also raise questions about whether you want the variable
history information too? (or will in future?)

> Our intended use of Toaster is as the backend for an MCP server for AI agents.
> Rather than having agents repeatedly parse and search recipe files or invoke
> bitbake-getvar, the server would expose resolved, build-specific metadata
> through a stable API. The MCP layer is still under development, but per-recipe
> variable values are one of its planned endpoints. We chose Toaster because it
> already models builds, recipes, packages and variables; extending it avoids
> creating a separate metadata store. It will run headlessly in this use case,
> with the MCP server translating between Toaster’s API and the agent.

Thanks for the info, that does sound like an interesting use case for
it. It is reasons like this I've pushed back against deleting toaster!
Knowing a bit about your plans here does help me keep fighting to keep
that code!

I'd also note that your original patch is quite large and really should
make more increamental separte changes given the breadth of what it is
doing.

Cheers,

Richard