On Wed, Feb 21, 2018 at 3:49 AM, Martin Jansa <[email protected]> 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 <[email protected]> > wrote: >> >> On Tue, Feb 20, 2018 at 1:52 PM, Khem Raj <[email protected]> wrote: >> > On 2/20/18 9:13 AM, Bruce Ashfield wrote: >> >> On Tue, Feb 20, 2018 at 11:50 AM, akuster808 <[email protected]> >> >> 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 >> >>> [email protected] >> >>> 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 >> [email protected] >> 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 [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
