[OE-core] [Openembedded-architecture] LAYERSERIES

[Denys Dmytriyenko]

I understand the need to reduce the support burden. But there are some valid 
cases when you want to use components/layers from a different set of releases. 

It can sometimes be an older component in otherwise newer setup (i.e. one 
layer hasn't been updated yet from rocko, but it still works fine with 
everything else from sumo).

Alternatively, sometimes you need to bring a newer version of the component to 
your older release - as long as it works for me, I don't want this to be 
artificially restricted.

In other words, the intention is good, but it needs to be either more flexible 
or allow overriding this from distro config or local.conf...

-- 
Denys


On Fri, Apr 06, 2018 at 11:37:01AM +0100, Richard Purdie wrote:
> I finally found 5 mins to sit and look at where I'd gotten to with the
> LAYERSERIES variable handling. I sent out discussion about this a while
> ago but as a reminder:
> 
> We have a problem where people expect master branch of meta-X to work
> with OE-Core master. If meta-X hasn't been maintained for a long time,
> this may give all kinds of weird errors. This creates a large support
> burden and means we struggle to spot unmaintained/un-updated layers.
> We'd like to fix this.
> 
> In answer to this I added LAYERSERIES_CORENAMES to OE-Core and strongly
> suggest layers then set:
> 
> LAYERSERIES_COMPAT_xxx = "sumo"
> 
> in their layer.conf where xxx is the collection name (used elsewhere in
> layer.conf) to indicate which versions of OE-Core they're expected to
> work against.
> 
> The code already exists to validate this with a fatal error for
> mismatches. What was missing was:
> 
> a) to print a warning if LAYERSERIES_COMPAT_xxx is unset. I've a patch 
>    queued for bitbake to add this.
> b) add a check to yocto-check-layer and require this to be set for YP 
>    Compatible v2. I've added
>    https://bugzilla.yoctoproject.org/show_bug.cgi?id=12661
>    to track this.
> 
> Yes, its late in the release and the warnings will be annoying but I
> think its worth fixing this now so I'm pushing ahead to resolve this.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture