[oe] Splitting meta-oe?

[Bruce Ashfield]

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"