[OE-core] RFC: Layer tooling brainstorming

[Martin Jansa]

On Mon, Apr 18, 2011 at 10:01:59AM +0200, Koen Kooi wrote:
> 
> Op 18 apr 2011, om 09:09 heeft Richard Purdie het volgende geschreven:
> 
> > On Mon, 2011-04-18 at 08:50 +0200, Martin Jansa wrote:
> >> On Mon, Apr 18, 2011 at 07:17:01AM +0100, Richard Purdie wrote:
> >> 
> >> maybe I've missed something, but
> >> * Parsing error when ie foo_1.0.bbappend is found, but foo_1.0.bb in
> >>  upper layer was upgraded to foo_1.1.bb
> >> 
> >> This can cause big problems when distribution explicitly enables
> >> something in .bbappend with EXTRA_OECONF, and someone updates all
> >> layers, builds foo_1.1.bb and installs it on targets before noticing
> >> that foo_1.0.bbappend wasn't used. Then he has to bump PR after adding
> >> foo_1.1.bbappend to distro layer (to fix foo on targets), so I would
> >> prefer parsing error in this case (won't help if upper layer keeps both
> >> versions foo_1.0.bb and foo_1.1.bb ;/).
> >> 
> >> This should be combined with your 2nd point and person who changes
> >> versioned dependency on upper layer should check that all needed
> >> .bbappends still apply.
> > 
> > Agreed but I thought we already had a tool to handle at least some of
> > this though? Certainly integration of that with the above is essential
> > though.
> 
> This is what I get for my setup:
> 
> koen at dominion:/OE/tentacle/build$ bitbake-layers 
> <string>:1: DeprecationWarning: Call to deprecated function bb.parse.parse_py.BBHandler.vars_from_file: Please use bb.parse.vars_from_file instead.
> <string>:6: DeprecationWarning: Call to deprecated function bb.which: Please use bb.utils.which instead.
> WARNING: Bitbake has not been run using the bitbake wrapper (scripts/bitbake); this is likely because your PATH has been altered from that normally set up by the poky-init-build-env script. Not using the wrapper may result in failures during package installation, so it is highly recommended that you set your PATH back so that the wrapper script is being executed.
> WARNING: Pseudo is not functioning correctly, which will cause failures during package installation. Please check your configuration.
> Parsing recipes..<string>:1: DeprecationWarning: Call to deprecated function bb.which: Please use bb.utils.which instead.
> <string>:1: DeprecationWarning: Call to deprecated function bb.which: Please use bb.utils.which instead.
> <string>:1: DeprecationWarning: Call to deprecated function bb.which: Please use bb.utils.which instead.
> done.
> INFO: State of append files:
> INFO: base-files_3.0.14.bb:
> INFO:   /OE/tentacle/sources/meta-angstrom/recipes-core/base-files/base-files_3.0.14.bbappend
> INFO: libusb-compat_0.1.3.bb:
> INFO:   /OE/tentacle/sources/meta-openembedded/meta-oe/recipes-support/libusb/libusb-compat_0.1.3.bbappend
> INFO: sysvinit_2.88dsf.bb:
> INFO:   /OE/tentacle/sources/meta-angstrom/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
> koen at dominion:/OE/tentacle/build$ 

This is great for distro maintainer who maintains also those required
revisions for upper layers, if distro building scripts (oebb.sh or our
SHR Makefile) allows such revision locking.

But I don't expect regular distro builder to do such test after every
git pull in some layer (that's why I think parsing error would be
better).

My workaround for revision locking is using branches oe-core-contrib/shr
meta-oe-contrib/shr from SHR Makefile, where I can stash some patches
not yet applied from pull request or even not yet sent in any pull
request and also control which upstream revision will be used (rebased
on).

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com