[Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 09:49) Martin Jansa wrote: > > I need an updated python-<foo> package for an unrelated package > > And how far will you go? > > If you want just newer python-<foo> and nothing else, will you take other > changes to other python-* recipes from meta-python layer? There is a lot of > recipes there, if you're so picky about updates, then you shouldn't update > whole oe-core as well.
It seems like this part is already settled, but it would seem to me that this scenario, if I understand it correctly, is "I'm using oe-core and see up-stream meta-oe/meta-somethingorother has an updated or new recipe for something I want in my image but I don't want to do a pull on all of meta-oe and potentially cause a huge rebuild of stuff I don't really care about". That sounds like a problem better solved with 'git branch', 'git fetch' and 'git cherry-pick' on the developer's side than breaking up meta-oe across existing meta-boundaries. -J. > > On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield <bruce.ashfi...@gmail.com> > wrote: > > > On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj <raj.k...@gmail.com> wrote: > > > On 2/20/18 9:13 AM, Bruce Ashfield wrote: > > >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 <akuster...@gmail.com> > > 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 > > >>> Openembedded-devel@lists.openembedded.org > > >>> 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 > > Openembedded-devel@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > > -- -Joe MacDonald. :wq
signature.asc
Description: PGP signature
-- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel