Hi Konstantin,

On 1/3/23 16:58, Konstantin Kletschke wrote:

On Mon, Jan 02, 2023 at 05:11:35PM +0100, Quentin Schulz wrote:

but this is now deprecated for kirkstone and should be done this way:

RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""

This makes sense, I'll send a patch updating the documentation to reflect
this change. I thought we already had discussed about this and someone sent
a patch but doesn't seem so :/

Thank you :-)

So I believe you need to add:
MACHINE_EXTRA_RRECOMMENDS:beaglebone-yocto = ""
MACHINE_ESSENTIAL_EXTRA_RDEPENDS:remove:beaglebone-yocto = "kernel-image
kernel-devicetree"
RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
to your local.conf

Dear Quentin, this is correct. It worked this way.
I admit, I was not aware the config snippets I copied need to be
modified for the local.conf in a way the machine name has to be
appended!

So, you needed the extra :beaglebone-yocto because the machine configuration file is parsed after local.conf, therefore since beaglebone-yocto.conf file has:
MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
your local.conf changes would be overridden while parsing the machine configuration file.

By using the OVERRIDE mechanism, we kinda cheat this by making the variables in local.conf "more important" than the machine conf file's.

You don't need the :beaglebone-yocto OVERRIDE for the :remove but it's "better" this way so that if you build multiple machines with the same local.conf, you don't impact other machines as well.

I suggest you create your own machine configuration file which requires
beaglebone-yocto.conf where you'll be able to set:
MACHINE_EXTRA_RRECOMMENDS = ""
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""

Meanwhile I did something similair, I cloned the machine
beaglebone-yocto into my tree with thos modifications on top and this
works too.

Would highly recommend not doing that though, having two configruation files with the same filename is not nice to your users, because then the order of inclusion of the layers will decide which file gets picked.

Create your own my-beaglebone and in there have:
MACHINEOVERRIDES =. "beaglebone-yocto:"
require conf/machine/beaglebone-yocto.conf

The first line will allow recipes to use the :beaglebone-yocto OVERRIDE to match both the original beaglebone-yocto and your my-beaglebone machines.

Thanks for your enormous useful hint to the modification needed for
local.conf and the tip to create a machine, inherit beaglebone-yocto and
modify those three variables.

You can check the value of a variable by running bitbake-getvar -r
virtual/kernel MACHINE_EXTRA_RRECOMMENDS for example.

Thank you, very useful.
Meanwhile I found out, for my puspose it could be useful to do something
like
CORE_IMAGE_BASE_INSTALL:remove = " packagegroup-core-boot packagegroup-base-extended"

Be careful, :remove are final, you cannot re-add its content later on. SO if you expect users to reuse and extend your image recipe while having :remove in there, you'll have unhappy users :)

in the image config, which might be even more useful for my approach to
my use case.
I now can approch my goal with local.conf, an additional machine or the
CORE_IMAGE_BASE_INSTALL modification.
One question though:
can the MACHINE variable only be modified in the local.conf (the
reference manual - glossary does not mention other places)?

It can be modified in any configuration file I believe, though local.conf is the only one that makes sense to me, anything else is bad practice.

However, you can pass MACHINE=my-beaglebone to bitbake, e.g.:
MACHINE=my-beaglebone bitbake my-image

would build my-image for this machine specifically.

If I go with the additional machine approach I am searching for a way to
build different images in my distro based on different machines. Is that
possible?

What exactly should be different between your images per machines? If we're talking about some specific BSP components differing (e.g. kernel, bootloader, tf-a, op-tee, etc... basically anything NOT userspace), it's better IMHO to specify those machine specific packages as MACHINE_EXTRA_RRECOMMENDS or MACHINE_ESSENTIAL_EXTRA_RDEPENDS in your machine configuration file. If it's something else, you can either (ab)use the OVERRIDE mechanism (:my-beaglebone) to specify packages to install only for one machine. E.g. in your image recipe:
IMAGE_INSTALL:append:my-beaglebone = " some-my-beaglebone-package"

If you want the same package but in different version or a different implementation (e.g. dropbear vs openssh, barebox vs uboot), have a look at virtual recipes (you can find consumers of those virtual recipes where virtual/somthing is used).

Finally, it might make more sense to just have multiple image recipes, each machine having its own image recipe for example.

Remember, distro is for policy (should my system be configured to run with x11, wayland, alsa, whatever), machine is for HW and recipes are for SW applications configured for a given policy and compiled for a given machine. If your HW is identical but you want some differences in your images, you might want to have a look at distro configruation files rather than different machines (at least on the theoretical and best practice level, it's the preferred way).

Cheers,
Quentin