[oe] Splitting meta-oe?

[Martin Jansa]

> 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.

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
>