On Wed, Feb 5, 2025 at 3:37 PM Alexander Kanavin <[email protected]> wrote: > > Btw the other option for overriding fragments would be to use direct require > statement with a path to them in local.conf, followed by tweaks. It’s not too > horrible. And using a fragment variable can then be seen as ‘immutable’ > fragment enabling which could be beneficial precisely because users can’t > mess with it.
Sure, and I've done that before. I assumed this was intended to replace that behavior with a nicer UI, but apparently that was not the goal? > > Alex > > On Wed 5. Feb 2025 at 23.26, Alexander Kanavin via lists.openembedded.org > <[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. >> >> 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 (#210885): https://lists.openembedded.org/g/openembedded-core/message/210885 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]] -=-=-=-=-=-=-=-=-=-=-=-
