[oe] [OE-core] [RFC] Layers, PRINC and bbappends

[Koen Kooi]

Op 15 mei 2013, om 22:33 heeft Richard Purdie <richard.purdie at 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core