Re: [bitbake-devel] [PATCH] bitbake-setup: support --update-bb-conf on init and fix site.conf symlink for setup-dir == top-dir

On Thu, 2 Jul 2026 at 16:23, Daniel via lists.openembedded.org
<[email protected]> wrote:
>   Two fixes that work together to let "bitbake-setup init" preserve an
>   existing bitbake build configuration (local.conf, bblayers.conf):
>
>   1. Expose the existing update_bb_conf parameter through a new
>      --update-bb-conf CLI flag on init, matching the semantics of
>      "bitbake-setup update". This lets downstream projects re-run init
>      (e.g. to refresh layers via --source-overrides) without losing
>      their tracked conf files. The default remains "yes" for backward
>      compatibility, so a fresh init is unaffected.

'Init' is explicitly meant for initializing a new setup, not for
operating on something that was already initialized before. There's
even code to check for it:

    if os.path.exists(os.path.join(setupdir, "layers")):
        logger.info(f"Setup already initialized in:\n
{setupdir}\nUse 'bitbake-setup status' to check if it needs to be
updated, or 'bitbake-setup update' to perform the update.\nIf you
would like to start over and re-initialize in this directory, remove
it, and run 'bitbake-setup init' again.")
        return

So I think such after-the-fact tweaks should be in 'update'.

>   2. Fix the site.conf symlink target when the setup directory is the
>      same as the top directory. The target was always computed as
>      setupdir/../site.conf, which only matches the actual site.conf
>      location (top_dir/site.conf) when the setup directory is exactly
>      one level below the top directory. When --setup-dir-name is given
>      an absolute path equal to the top directory, the symlink ends up
>      broken, which causes "diff -uNr" to fail with exit code 2 inside
>      setup_bitbake_build(). That exception is raised before the
>      update_bb_conf == 'no' branch can restore the original conf,
>      defeating the new flag from #1. Prefer setupdir/site.conf when it
>      exists, falling back to the previous behaviour otherwise.

Setup directory is as well meant to be exactly one level under the top
directory, not the same as the top directory or somewhere else
entirely. We probably should add more guards and useful messages when
that is not the case, but we shouldn't try to support that.

Apologies if this answer is not what you expected, but perhaps you can
describe the use case first?

Alex