[oe] Splitting meta-oe?

Wed Feb 21 13:45:09 UTC 2018

[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.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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20180221/9ecb29e9/attachment-0002.sig>