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-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture -- _______________________________________________ Openembedded-core mailing list Openembeddedemail@example.com http://lists.openembedded.org/mailman/listinfo/openembedded-core