[oe] [RFC] Layers, PRINC and bbappends

[Koen Kooi]

Hi,

For the past 2 weeks I've been trying to fix the angstrom feeds manually due to a combination of PRSERV deciding that going backwards is OK and multiple layers getting updates that make PR go backwards as well.

Getting a simple reduction for PRSERV going backwards is nigh impossible[1], so I can't complain too much about that, but I can complain about what people do :)

What triggered PR going backwards this time was a BSP removing its netbase bbappend because it wasn't needed anymore. That's great, I hate netbase bbappends since they tend to be ifupdown specific and don't work as intended with connman/NM/netctl/etc. Long story short:

	ERROR: Package version for package netbase-dbg went backwards which would break package feeds from (0:5.0-r3.1 to 0:5.0-r1.2)
	ERROR: Package version for package netbase-staticdev went backwards which would break package feeds from (0:5.0-r3.1 to 0:5.0-r1.2)
	ERROR: Package version for package netbase-dev went backwards which would break package feeds from (0:5.0-r3.1 to 0:5.0-r1.2)
	ERROR: Package version for package netbase-doc went backwards which would break package feeds from (0:5.0-r3.1 to 0:5.0-r1.2)
	ERROR: Package version for package netbase-locale went backwards which would break package feeds from (0:5.0-r3.1 to 0:5.0-r1.2)
	ERROR: Package version for package netbase went backwards which would break package feeds from (0:5.0-r3.1 to 0:5.0-r1.2)

To avoid things like that in the future I have a few recommendations I'd like to get feedback on:

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]


2) *Never* use PRINC in type b) bbappends

3) Avoid PRINC in general

4) make buildhistory.bbclass mandatory in OE-core

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

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

Thanks,

Koen

[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