Op 15 mei 2013, om 22:33 heeft Richard Purdie <richard.pur...@linuxfoundation.org> het volgende geschreven:
> On Tue, 2013-05-14 at 09:36 +0200, Koen Kooi wrote: >> To avoid things like that in the future I have a few recommendations >> I'd like to get feedback on: > > In future can we please discuss this on the oe-core list or at least > give a heads up there as this is pretty key to the core of the project > and we've implicitly agreed to discuss architecture there? I appreciate > this affects oe-devel layer maintainers too. I meant to send it to oe-core, but I didn't check autocomplete. Anyway, seems I reached the people I wanted to reach :) > >> 1) For a given BSP split it in multiple layers: >> a) One 'core' BSP layer with only: >> o Bootloader >> o Kernel >> o Tooling to build bootloader/kernel/image >> b) One BSP layer with bbappends for shadow/netbase/xorg-conf/etc >> c) One or more layers with bbappends for libav/clutter/etc[2] > > You're missing d) which would presumably be everything not in a-c) e.g. > binary graphics libs which aren't bbappends. I'd group those with c) > I have a feeling this will break more than it solves so I'm not keen on > this and I think we need to dig deeper into the problem and find a > better solution. >> >> 2) *Never* use PRINC in type b) bbappends >> 3) Avoid PRINC in general > > Could we undergo some mass purge of PRINC from master branches and then > change the PR values once and for all in the core recipes? We could make > PRINC throw a bb.fatal() from that point onwards. That would be nice. > >> 4) make buildhistory.bbclass mandatory in OE-core > > and force enable the PR backwards check? Yes > Again, I think the people > you're trying to target to fix these issues are also the people who'd > probably not have the history around to see the issues that most bother > you. True, but they'd have less plausible deniability :) > I agree there are some issues here but I think we're going to need a > more creative fix. > > My personal view is we need to reduce the number of bbappends. One way > to do this is to make a general/central bsp-files type recipe which > generates all the standard packages (tscalibration data, xorg config and > all the other single machine specific config files). > > Yes, this would be a disruptive change but it would significantly clean > up the BSP layers and hopefully make maintenance easier. It is on the > Yocto project proposed features list although we've only got the idea, > we haven't discussed with the community etc. Now would see as good a > time as any. > >> There's another use case that suffers from PRINC problems and that is >> removing layers when they break parsing and the maintainer is slow to >> push patches. With the current situation I have to choose between >> "being able to do builds" and "having working feeds". > > We have talked about a version wildcard for bbappend. You are still at > the mercy of what the bbappend does though (e.g. when I include > meta-raspberrypi, it changes the psplash logo, regardless of whether I'm > building for the pi). > > In many ways the bbappend is too easy and encourages anti-social > behaviour. The funny thing is that I've run into bb(appends) trying to be social and breaking things, e.g. linux-yocto.bbappend: SRC_URI = "git://foo" SRCREV_mymachine = "1849032784092359023" ANOTHER_VAR_mymachine = "meta" And that breaks parsing for every machine that isn't named "mymachine". > I would recommend bouncing meta-rpi as being non yocto > project compatible due to the psplash issue if it were to apply which it > has not. > >> During the last TSC meeting we discussed that there is currently no >> way to force maintainers to behave. I think the most we can do is have >> clear guidelines on the OE side and enforce those during the "Yocto >> Project Compatible" process. > > How many layers apply for that status though? Ideally all of them. regards, Koen >> And have the layer index orange/red flag layers that do stupid things. >> Come to think of it, that would actually be the most visible way to >> go, having wikipedia style warning banners on the offending layers. > > I think Paul had good feedback here. > >> [1] It always happens after editing bblayers.conf and dragging in >> major update to layers. Since I tend to do both at the same time I >> can't say which action triggers it or if it's the combination. >> [2] I spent 3 days trying to figure out why mesa was so *$(*$(@ broken >> before I finally located the bbappends in meta-ti that were causing >> this breakage > > I do appreciate understanding where some of the problem arises from, > thanks! > > Cheers, > > Richard > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core