In an experimental branch of refkit I bumped LCONF_VERSION from 4 to 5 and ran into the problem mentioned in the commit message: instead of raising an error as before, the code (incorrectly) claimed to have updated the bblayers.conf file.
Perhaps refkit should have started with LCONF_VERSION as in the current OE-core bblayers.conf.sample file to avoid being affected by this - too late for that now, though. As an ugly workaround I'm currently jumping from 4 to 8 directly, which produces some extra (and wrong) output about "automatically updated" before finally raising the expected error (twice, for some reasons). I'm not sure how this code was meant to work for different distros based on OE-core. Depending on when a distro forked from OE-core and how it continued with numbering its bblayers.conf.sample file, there must have been such conflicts already before. Note that I have only checked that the code gets called when placed in the expected location, and the code itself was copied verbatim. As it refers to ancient changes, I've not actually tried to set up a build dir where that upgrade path is necessary. Perhaps the code could even be removed entirely? Patrick Ohly (1): bblayers sanity: bblayers.conf.sample specific update code meta/classes/sanity.bbclass | 121 ++++------------------- meta/conf/lib/bblayers_update/__init__.py | 104 ++++++++++++++++++++- 2 files changed, 130 insertions(+), 95 deletions(-) create mode 100644 meta/conf/lib/bblayers_update/__init__.py base-commit: ccf630e78aad488da7b80f2981037d3d0559cfad -- git-series 0.9.1 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core