On Fri, 2018-04-06 at 20:25 +0200, Martin Jansa wrote: > FWIW: I've updated some layers with this LAYERSERIES_COMPAT_<layer> > today and I think it's good idea.
Thanks. I know its late in the cycle but I think it will help. > It probably won't be enough to stop questions like this: > http://lists.openembedded.org/pipermail/openembedded-core/2018-April/ > 149696.html If the layers did have the settings I think it would have fatally errored out before that. The way this was designed, it will not parse further that the layer.conf files if mismatch is detected. > but it's still better to show warning first and then some often > harder-to-read exception or error log. Agreed. > Updating layer.conf in meta-qt5 was a bit more tricky as people tend > to mix the meta-qt5 branches with different branches of other layers, > just because their requirements for Qt are often very different than > for other layers (e.g. many people still using meta-qt5/krogoth with > Qt 5.6 because of the license, even with much newer morty, pyro, > rocko, sumo, master branches of other layers and vice versa that > someone is stuck with krogoth release for whatever reason, but needs > newer LTS Qt 5.9 from meta-qt5/rocko). So for meta-qt5 I've used > multiple values for LAYERSERIES_COMPAT_<layer> for combinations I use > somewhere (so that I cover at least some testing with such uncommon > combination) and I'm willing to accept more values to it if someone > really uses another combination regularly. The rest of combination > (like meta-qt5/krogoth with dizzy, which is usable as described in > meta-qt5 commits which introduced incompatiblitites, will eventually > trigger the warning which is fine, because people should be aware > that they are doing something less tested and that they might to > implement some work arounds to make it usable). That sounds good. The system was flexible enough to allow "mismatch", *if* the layer maintainer supports it. I'm also not expecting people to backport this to older releases, just to start doing it now so things improve going forward. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembeddedfirstname.lastname@example.org http://lists.openembedded.org/mailman/listinfo/openembedded-core