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.


> 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.


Openembedded-core mailing list

Reply via email to