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
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
