ci/base.yml: convert to nodistro

[koenkooi]

Since Poky is both not meant nor suited for production, it shouldn't be the default choice for reference builds, downstream users tend to keep to the defaults, even the wrong ones.

Furthermore, since the configs are adding additional classes and changes, the result is not identical to upstream Poky anymore, leading to more confusion.

Switch to using straight OE-core and bitbake repos and set DISTRO to 'nodistro'.

Boot tested on rb3gen2:

root@qcs6490-rb3gen2-core-kit:~# cat /etc/os-release 
ID=nodistro
NAME="OpenEmbedded"
VERSION="nodistro.0"
VERSION_ID=nodistro.0
PRETTY_NAME="OpenEmbedded nodistro.0"
CPE_NAME="cpe:/o:openembedded:nodistro:nodistro.0"

[ndechesne]

This is big change. We need to discuss it more for sure, and we need to tie that to our 'distro' plans.

Is there an easy way to list the changes involved when moving from poky to nodistro? so that at least we know which one may or may not be important for us?

this layer is a BSP layer, so we don't want to make any distro choices there, but for our CI testing, we can use our CI configs.

[koenkooi]

There's not an easy way to view the difference, but with 'nodistro' the defaults are now in a single place, default-distrovars.inc: https://github.com/openembedded/openembedded-core/blob/master/meta/conf/distro/include/default-distrovars.inc

And like you say, this is a BSP layer, so we should not make any distro choices here, so 'nodistro' is the only realistic option for that. The README tells people to use the KAS based CI configs, so we can't argue those are purely for CI purposes anymore....

[ricardosalveti]

And like you say, this is a BSP layer, so we should not make any distro choices here, so 'nodistro' is the only realistic option for that.

I understand the reason for the proposed changes, but I would argue that poky is still the main distribution people test along with their respective BSP layers, so even if we move to 'nodistro', we would probably want to validate with 'poky' as well.

Poky does brings some additional classes and distro features when comparing with 'nodistro'. In the end we will just have to decide which distro we will use as base for validating the BSP layer, with whatever other distro features and extensions required for us to build and validate what the BSP layer is offering. We will also test with meta-qcom-distro, but that is more a reference distribution to integrate all the qcom sauce instead of something we would want people to base products on.

The README tells people to use the KAS based CI configs, so we can't argue those are purely for CI purposes anymore....

That is just for convenience as this is what we test, but we don't enforce kas or such configs in the end.

[koenkooi]

I understand the reason for the proposed changes, but I would argue that poky is still the main distribution people test along with their respective BSP layers, so even if we move to 'nodistro', we would probably want to validate with 'poky' as well.

Sure, but we'd need to validate against an unmodified Poky in that case.

[koenkooi]

[...] In the end we will just have to decide which distro we will use as base for validating the BSP layer, with whatever other distro features and extensions required for us to build and validate what the BSP layer is offering.

The important thing is that when we validate our BSPs using 'external' DISTROs, we do so without modifying them. If we need, for techinical reasons, to modify a DISTRO, we should create our own named DISTRO and document the needed features and/or use 'nodistro'.

We will also test with meta-qcom-distro, but that is more a reference distribution to integrate all the qcom sauce instead of something we would want people to base products on.

And that's the hard, non-technical part :) People consuming BSPs tend to use the 'default' because they assume that's what will work best. Now that Poky is finally clamping down on getting modified and being used in production, the average BSP consumer will then try to use the vendor provided DISTRO. Which for various non-technical reasons also shouldn't be used in production.

So ideally our BSP would show:

1. Being able to work with the defaults (e.g. nodistro)
2. Fully enabling all the hardware features and optimizing for it (e.g. meta-qcom-distro)
3. Not getting broken by the non-default choices popular DISTROs make (e.g. Poky)