[oe] Splitting meta-oe?

[Bruce Ashfield]

On Wed, Feb 21, 2018 at 3:49 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
>> I need an updated python-<foo> package for an unrelated package
>
> And how far will you go?
>

pretty far. I work with a lot of deep stacks that have a lot of specific
dependencies as well as compatibility issues.

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

I actually don't always, but generally speaking, I haven't had many
problems with package updates from oe-core. I end up with breakage
due to core build system changes, and that impacts oe-core and any
layer either.

But as I pointed out, I'm not looking to have my problem 'solved', I'm
just pointing out that it is a valid concern .. whether or not others
agree.

Cheers,

Bruce

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



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