Proposal for Adding OE/Yocto-Style Features Variables to Isar

["'Christopher Larson' via isar-users" <isar-users@googlegroups.com>]

Dear Isar Users,

I would like to start a discussion about the possibility of supporting 
OE/Yocto-style features variables within the Isar project. Currently, 
Isar implements BASE_REPO_FEATURES and ROOTFS_FEATURES, which are quite 
useful. However, I believe that adding support for DISTRO_FEATURES, 
MACHINE_FEATURES, and possibly IMAGE_FEATURES would be worthwhile 
additions to consider.

I want to preface this by acknowledging that my perspective is 
influenced by decades of experience with OpenEmbedded (OE) and OE-based 
products. I recognize that Isar has a different philosophy, favoring 
more direct approaches and fewer abstractions compared to OE.

That said, I believe the value of these abstractions may justify the 
added complexity. It seems that many downstreams end up reinventing 
similar mechanisms for their own needs. For example, CIP adds 
INSTALL_WIRELESS_TOOLS, USE_CIP_KERNEL_CONFIG, and CIP_IMAGE_OPTIONS, 
the latter being a list of .inc files required by an image to allow for 
metadata reuse. Our usage at Siemens includes similar reinventions as well.

Certainly, we could leverage ROOTFS_FEATURES for certain rootfs/image 
capabilities beyond the existing postprocessing in Isar. Establishing a 
convention for including optional rootfs/image capabilities could avoid 
metadata duplication, simplify managing development vs. production 
filesystems, and provide customization mechanisms for downstreams.

Regarding DISTRO_FEATURES and MACHINE_FEATURES, the Yocto documentation 
covers them in general. The original intention was to allow for a 
mechanism similar to Gentoo’s USE flags, coupled with OE’s three 
orthogonal axes of distro, machine, and image. The intersection of these 
would control the outcome, allowing any combination to be viable. This 
results in machine support that is not tightly coupled to distro 
capabilities or policy decisions, avoiding the pattern of each 
downstream copying and modifying both distro and machine in a single 
layer. This decoupling could prevent issues like machines installing 
packages such as expand-on-first-boot unnecessarily.

In OE, the intersection of these features determines certain 
functionalities. A common example is hardware capabilities like WiFi or 
Bluetooth, where the distro expresses a desire to support certain 
functionalities. Only if both the distro and machine support it will the 
required packages be installed.

Details would need to be worked out, even if it is determined that this 
provides more value than it adds in complexity. The core of the global 
features in OE is their intersection in packagegroup-base, which 
determines the default installed packages in images built from the 
ground up. While this doesn’t make sense in Isar with a Debian base 
image, there are still optional functionalities requiring package 
installation. Often, this requires more than just a single 
IMAGE_PREINSTALL line, so there’s value in having a simpler way to 
express a desire to support that functionality. Isar may not need to 
utilize this functionality directly, but it could be beneficial to 
provide it for downstream use.

Downstreams can and do implement functionality like this if they want 
to, so I understand the argument for continuing this approach. However, 
I believe there is value in providing basic functions to utilize such 
capabilities and documented conventions for doing so consistently.

I would love to hear what both Isar core developers and downstream 
developers think about the possibility of providing a mechanism for 
using variables like these. I believe that the ability to provide an 
easier customization mechanism and an abstraction to better separate 
concerns between the distro, machine, and images would be valuable. It 
would also ease rootfs customization based on desired system features 
(distro) and hardware capabilities (machine), if one uses these to 
adjust ROOTFS_FEATURES.

I don’t believe the default behavior of OE’s IMAGE_FEATURES, where 
package lists are defined in FEATURE_PACKAGES_, is worth including here. 
It’s not difficult for developers to manually implement package grouping 
using features if needed, and it’s often better to create separate 
packages if multiple dependencies should be pulled in at once.

Looking forward to your thoughts and feedback.

Best regards,
-- 
Christopher Larson
Siemens AG
www.siemens.com

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/27f2f225-d7c4-40dd-a4db-431eeb31cc52%40siemens.com.