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

[Anton Mikanovich <amikan@ilbers.de>]

25/09/2024 23:27, 'Christopher Larson' via isar-users wrote:
> 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,

Hello Christopher,

I agree that adding at least some part of OE-style 'features' can be useful
for existing and potential downstreams, especially for big vendor layers.
But we should carefully think about the implementation itself, because, as
you've already mentioned, Isar can only provide an APIs (without adding too
much packages into base minimal image), but every API should be used in
meta-isar/meta-test layers and covered by CI.
Maybe we can migrate our current example packages from local.conf to some
new package group with adding 'features' filtering as a first step.

-- 
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/0ff24b5e-41a7-4aab-8a02-906774cf8af8%40ilbers.de.