Agreed with Rudolf.

If the layer maintainer didn't bother to do at least do one build with new release and adjust LAYERSERIES_COMPAT, then I don't consider that layer well maintained (it could be someone else who uses the layer, tests it with new release and sends PR to adjust LAYERSERIES_COMPAT).

Recently I've also seen this:
LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"

which is also bad as it completely disables the check (seen in https://git.phytec.de/meta-phytec/tree/conf/layer.conf#n14).

On Thu, Dec 1, 2022 at 7:06 AM Rudolf J Streif <rudolf.streif@...> wrote:

On Wed, Nov 30, 2022, 20:27 Zoran <zoran.stojsavljevic@...> wrote:

Hello to Yocto community,

As I am much more passive yocto wise these few years ( working on
Android build systems and around, this is also a nightmare, I should
say ;-) ), I have one Yocto question which I never really understood.

I will ask it by example. I have one layer for the CAN tools and apps
which I have created 4 years ago:
https://github.com/ZoranStojsavljevic/meta-socketcan

In there, in conf/layer.conf:
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/conf/layer.conf

I have the following line (layers' compatibility):
LAYERSERIES_COMPAT_meta-socketcan = "sumo thud warrior zeus dunfell
gatesgarth hardknott honister kirkstone"

I do not understand why we need to explicitly name releases for such
simple generic layers?!

To me this indicates that the maintainer of the layer has tested the compatibility of his layer with all of these releases of the Yocto Project.

A maintainer of a layer should make a deliberate decision of adding a release or dropping one from the compatibility list. It should be an attestation that the layer's compatibility with the releases in the list is actually maintained and tested.

There have been changes to the syntax to conditional variables. Your layer might well be compatible with all of the releases and it's great if you tested it. But it's not a given.

Instead, for a virtual example:
LAYERSERIES_COMPAT_meta-socketcan = "${AUTOLAYER x}"

So all the layers might be included (or for at least lets say x = 4
latest releases, where x = 0 would be include all)? I do understand
that complex layers could NOT have such a definition (because of the
dependencies), but for the generic layers (as such presented), this
would be beneficial.

I never cared for ${AUTOREV}, which is similar, in the first place for the very reason that it creates inconsistent behavior. This would do the same thing. What would the last 4 releases even mean? What is the reference and where is it obtained from?

Thank you for the answers,
Zee

_______

Best,
:rjs

On 1 Dec 2022, at 04:27, Zoran via lists.yoctoproject.org <zoran.stojsavljevic=gmail.com@...> wrote:

I do not understand why we need to explicitly name releases for such
simple generic layers?!

The compatibility is because over time things change: override syntax has changed, classes get added or removed, functionality may appear in bitbake. Sometimes the breakage is subtle, and a layer may parse and appear to build fine, but be broken.

Your meta-socketcan layer is broken in honister onwards despite claiming compatibility, for example.

Ross

On Thu, Dec 1, 2022 at 12:09 PM Ross Burton <ross.burton@...> wrote:

On 1 Dec 2022, at 04:27, Zoran via lists.yoctoproject.org <zoran.stojsavljevic=gmail.com@...> wrote:

I do not understand why we need to explicitly name releases for such
simple generic layers?!

The compatibility is because over time things change: override syntax has changed, classes get added or removed, functionality may appear in bitbake. Sometimes the breakage is subtle, and a layer may parse and appear to build fine, but be broken.

Your meta-socketcan layer is broken in honister onwards despite claiming compatibility, for example.

And here is another example why nobody should be using meta-socketcan:
https://github.com/ZoranStojsavljevic/meta-socketcan/commit/cefd86cd1def9ad2e63be527f8ce36a076d7e17c#

You cannot change the declared LICENSE of the components, just because you wish them to use the same license as the layer metadata, especially when those components clearly declare different LICENSE in the source code, e.g.:
https://github.com/linux-can/socketcand/commit/a7ab9878d11ac187b92dcf48b6331c228f4f4b92

Using COMMON_LICENSE_DIR in LIC_FILES_CHKSUM is another anti-pattern which just disables whole purpose of LIC_FILES_CHKSUM and this is acceptable only for "pure-metadata" recipes like packagegroups or image recipes.

On 1 Dec 2022, at 12:46, Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:

But, could you, please, allow me to have my own original cannelloni
recipe (yes, I developed it with some help from this community) on my
own terms? I DID not copy it from anywhere. It is an ORIGINAL.

As I explained in the bug I filed in your repository, the LICENSE statement is the license of the contents of the packages, not the recipe itself.

https://github.com/mguentner/cannelloni clearly says GPLv2.

Ross

On Thu, 1 Dec 2022 at 17:41, Rudolf J Streif <rudolf.streif@...> wrote:

Recently I've also seen this:
LAYERSERIES_COMPAT_phytec = "${LAYERSERIES_COMPAT_core}"

Oh no, now the entire Yocto Project world knows about this hack. Now we
need a sanity checker for this in the insane class. :)

It's a slippery slope. We can also for example make bitbake forcibly
not expand any variables in it, and write out an angry rant when
someone tries, and then I'm sure determined people will find a way
around that too.

Alex