On Wed, Feb 5, 2025 at 3:26 PM Alexander Kanavin <[email protected]> wrote: > > One could conceivably want to ship a local.conf.sample template with > fragments already enabled in it, or hand edit local.conf to enable something > via fragment. We can’t force users to use fragment tooling. > > It would be equally surprising to find out that setting fragments this way > doesn’t actually have any effect. > > I understand your argument, it’s just that we’ve taken the least worst > option. Consider fragments as extensions of distro and machine configurations > - both come after local.conf and can’t be tweaked from it.
That's an expected design choice; we already have MACHINE and DISTRO which work pretty well, so I though config fragments were intended to standardize the part that is more difficult e.g. setting configuration files from source control roundabout the time of auto.conf, since that is where all the different mechanisms that have cropped up do. > > Alex > > On Wed 5. Feb 2025 at 22.55, Joshua Watt <[email protected]> wrote: >> >> On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin <[email protected]> >> wrote: >> > >> > We have discussed this before. With this change, users will no longer be >> > able to set fragments from local.conf, as addfragments would be processed >> > before that file. You need to use ?= in fragments instead for things that >> > are meant to be overridden. >> >> Is there need to set fragments from local.conf? IMHO, not being able >> to override a fragment in local.conf is "surprising" behavior, and I >> don't think it's going to necessarily be possible to alway use ?= in a >> fragment; all of the ad-hoc "fragment" management systems I've used >> before have allowed local.conf to be the final source of truth, so it >> will also make migration to use config fragments harder if they don't >> follow suite. >> >> Anyway, maybe some other users of "fragment" like systems can chime in >> if they have an opinion. >> >> > >> > Alex >> > >> > On Wed 5. Feb 2025 at 22.24, Joshua Watt <[email protected]> wrote: >> >> >> >> Per some usability assessment and offline discussion, one of the useful >> >> use cases of config fragments is that they allow the "default" >> >> configuration for some device to be committed to source control and >> >> easily selected and used by the end users. However, when doing this, >> >> there is still the desire that the user can "override" the provided >> >> fragments for their local builds in local.conf >> >> >> >> As a practical example, the configuration for a product can be capture >> >> as a config fragment, and an empty local.conf will reproduce the >> >> standard build for the product. If the user wants to make "tweaks" to >> >> the standard build, they can do so in local.conf >> >> >> >> As such, move the config fragments to be loaded before local.conf >> >> >> >> Signed-off-by: Joshua Watt <[email protected]> >> >> --- >> >> meta/conf/bitbake.conf | 3 ++- >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf >> >> index 8b607088c6e..d0154044f5a 100644 >> >> --- a/meta/conf/bitbake.conf >> >> +++ b/meta/conf/bitbake.conf >> >> @@ -826,12 +826,13 @@ FILESOVERRIDES = >> >> "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDE >> >> require conf/abi_version.conf >> >> include conf/site.conf >> >> include conf/auto.conf >> >> -include conf/local.conf >> >> >> >> OE_FRAGMENTS_PREFIX ?= "conf/fragments" >> >> OE_FRAGMENTS_METADATA_VARS ?= "BB_CONF_FRAGMENT_SUMMARY >> >> BB_CONF_FRAGMENT_DESCRIPTION" >> >> addfragments ${OE_FRAGMENTS_PREFIX} OE_FRAGMENTS >> >> OE_FRAGMENTS_METADATA_VARS >> >> >> >> +include conf/local.conf >> >> + >> >> require ${@"conf/multiconfig/${BB_CURRENT_MC}.conf" if >> >> "${BB_CURRENT_MC}" != "" else ""} >> >> include conf/machine/${MACHINE}.conf >> >> include conf/machine-sdk/${SDKMACHINE}.conf >> >> -- >> >> 2.47.1 >> >>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#210884): https://lists.openembedded.org/g/openembedded-core/message/210884 Mute This Topic: https://lists.openembedded.org/mt/111021218/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
