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

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 25.09.24 22: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,

Thanks for the suggestion. As you mentioned already that you see
potential to re-model and unify existing public layers with such a
proposal, how about laying out how those would look like? Would make
this discussion a bit more concrete, specifically for those of us not so
long into OE like you are.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

-- 
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/ce2b37a9-c0bb-41e3-bb81-40625472ee84%40siemens.com.