[OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation

Aníbal Limón anibal.limon at linux.intel.com
Tue Feb 28 20:33:09 UTC 2017



On 02/28/2017 02:09 PM, Patrick Ohly wrote:
> On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
>> common.test_signatures: Test executed in BSP and DISTRO layers to review
>>     doesn't comes with recipes that changes the signatures.
> 
> I have a question about the goal for this test: is it meant to detect
> layers which incorrectly change the signatures of allarch recipes or
> recipes which share the same tune flags with other machines?

The requirement is DISTRO and BSP layers aren't allowed to automatically
change the MACHINE or DISTRO variable that causes the signatures to change.

> 
> Let's take MACHINE=edison as an example.
> 
> Modifying allarch creates a conflict with basically all other machines
> in a distro. Example for something not allowed:
> VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo /var/foo \n"
> 
> This can be detected by comparing against OE-core, but only when testing
> with MACHINE=edison.
> 
> More difficult to detect is modifying recipes with the same tune flags,
> which is the majority of the recipes. MACHINE=edison and
> MACHINE=intel-core2-32 both compile for the same target architecture, so
> something like this is incorrect:
> do_install_append_pn-base-files_edison () {
>     echo "Built for Edison" >>${D}${sysconfdir}/motd
> }
> 
> This can only be detected when testing with both MACHINE=edison and
> MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different
> tune flags (haven't checked).
> 
> My point is, the test probably needs to be extended to run with a set of
> machines, and that set of machines must be broad enough to cover a
> variety of common tune flags.

It is expected to change recipe signatures when the machine change, this
leaves me other question. what signatures are expected to change when
set a different MACHINE?

	Anibal

> 
> The corresponding selftest, test_sstate_sametune_samesigs in
> sstatetests.py, has the same limitation of its scope, i.e. doesn't
> actually test with real machine definitions.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170228/c96519d5/attachment-0002.sig>


More information about the Openembedded-core mailing list