On Thu, 16 Dec 2021 at 06:31, Fredrik Gustafsson <Fredrik.Gustafsson@axis.com> wrote:
bitbake has already support for non reproduceable builds, you can set SRCREV to a branch, which will change. This patch is actually for introducing reproducible builds, however the information is in git and not in bb-files.

The usecase here is traceability. Let's say you're developing a package and you want to integrate that to your bitbake system. It will require two commits, one to the package repository and one to the layer repository. You can get around this by settings SRCREV to a branch but then you no longer get reproduceable builds.

To solve this, we have built a service that once a package is updated, the bb-file in the layer repository is automatically rewritten so match the new version of the package. This is error prone and cumbersome. Using the layer repository as a superproject will made it possible to use gerrits superproject subscription that makes the layer repository to be updated each time the submodule (the package) is updated. This gives us reproduceable builds, only one commit to introduce a change and no inhouse developed services.

Apologies again, but without organizationally enforcing submodule structure this fetcher is not providing reproducible behaviour. If there are no source code checksums available for bitbake to verify during fetch, then there's no guarantee that the component repo has not been modified, and that guarantee must be technical, not organizational. The requirement for all fetchers is that they provide that ability: you can switch it off if you want to, but that is not allowed to be the default (or only) behavior.

If the problem is updating SRCREVs in a recipe, there is a standard, official way to do it: 'devtool upgrade'. Would that work for you?

Alex