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. > 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 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. > 4) make buildhistory.bbclass mandatory in OE-core and force enable the PR backwards check? 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. 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. 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? > 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