[oe] Splitting meta-oe?

Wed Feb 21 13:55:26 UTC 2018

On Wed, Feb 21, 2018 at 8:45 AM, Joe MacDonald <Joe_MacDonald at mentor.com> wrote:
> [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.

Agreed. I was just probing to see if anyone had ideas on how that could
be managed by infrastructure, versus me mucking about.

Maybe RP's thoughts on layer tooling or setup possibilities would help,
but either way, I'll keep chugging along :D

Cheers,

Bruce

>
> -J.
>
>>
>> On Wed, Feb 21, 2018 at 1:51 AM, Bruce Ashfield <bruce.ashfield at gmail.com>
>> wrote:
>>
>> > On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj <raj.khem at gmail.com> wrote:
>> > > On 2/20/18 9:13 AM, Bruce Ashfield wrote:
>> > >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 <akuster808 at 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 at 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 at lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>> >
> --
> -Joe MacDonald.
> :wq

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"