On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj <[email protected]> wrote: > On 2/20/18 9:13 AM, Bruce Ashfield wrote: >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 <[email protected]> wrote: >>> >>> >>> On 02/20/2018 02:45 AM, Burton, Ross wrote: >>>> Hi, >>>> >>>> Is now a good time to talk about splitting up meta-oe? Some layers are >>>> actively developed and maintained (one example: meta-python), others are >>>> basically bitrotting and only get touched when something else causes them >>>> to break world builds (one example: meta-gnome). I've long felt that >>>> meta-oe should be split up and the high quality layers managed in their own >>>> repositories so patches to them don't get held up by breakage in other >>>> sub-layers. >>> You make it sound like meta-oe is not a high quality layer. I could >>> make the same claim about oe-core master. >>> >>> I don't see the connection in patches being held up due to breakage in >>> other sub layers. This only happens if the dependency fail to build. >>> >>> You lose control over the quality in current layers that reside in >>> meta-openbedded just like you have no control over all the other layers >>> residing in the community. It makes maintaining stable versions very >>> difficult. Well, unless The Yocto Project takes over them.. I guess that >>> would work then. >>> >>>> >>>> Another advantage of splitting out the high quality layers is that we'd >>>> like to look at running more community layers through the Yocto >>>> autobuilder, and granular layers make that easier to manage. >>> I thought not including layers in bblayers.conf was easy enough. >>>> >>>> Comments? >>> >>> What problem do you thing you are trying to solve here? >> >> My unrelated issues are that I can't update one layer, without getting >> all of the updates. >> .. but that is both a good thing (i.e. they are all tested together, >> so you know that the >> single SRCREV update is good for all layers), and a bad thing (when >> you just want a >> new python recipe update from meta-python, but don't want other changes). >> > > if you dont include the layers in your BBLAYERS and they become > effectively non existent, unless you are on metered internet connection, > where downloading unused stuff would save you bandwidth, it should be > ok. No ?
Its not that. I *am* building the different layers, but say I have a stable set of packages and working images .. but for whatever reason, I need an updated python-<foo> package for an unrelated package, or some other layer that needs a newer version, etc. How do I get that, without taking updates to all the layers ? .. and layers that I really didn't want to update. I have to do some sort of combo-layer, carry my own copy of the recipe, etc. So there are definitely ways to do it, I'm just pointing out that I end up taking some build failures/issues from time to time on packages I didn't really need to update. The flip side of that argument is that all of the layers and sub layers have gone through some sort of global build, and hence I know that they all have worked together for someone. If I can update pieces individually, I break that .. and I own the broken bits after that .. which again, goes to my point that fixing one workflow/issue can break another :D Bruce > >> It is very likely that splitting the layer would help one issue, but >> make the other worse. >> >> So no solution from me, just an observation about potential issue. >> >> Cheers, >> >> Bruce >> >>> >>> - armin >>>> >>>> Ross >>> >>> >>> -- >>> _______________________________________________ >>> Openembedded-devel mailing list >>> [email protected] >>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> >> >> > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
