From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shymkent.ilbers.de ([unix socket]) by shymkent (Cyrus 2.5.10-Debian-2.5.10-3+deb9u2) with LMTPA; Mon, 30 Sep 2024 12:36:44 +0200 X-Sieve: CMU Sieve 2.4 Received: from mail-pf1-f192.google.com (mail-pf1-f192.google.com [209.85.210.192]) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPS id 48UAag62007199 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Sep 2024 12:36:43 +0200 Received: by mail-pf1-f192.google.com with SMTP id d2e1a72fcca58-718e2da2e33sf4633919b3a.1 for ; Mon, 30 Sep 2024 03:36:43 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1727692597; cv=pass; d=google.com; s=arc-20240605; b=k4Px+TMw1KtovnOMFmnW/XkFgeGEy5tdoOL5QGpuAWIfThzbk5G1vlhdBWXR9M6KSC B9gxnjnrXMSYjD2sSwVT6S7qDTTE+Fp1hxTavKHpgHSyoPCl6auhmdM7B7aq6L+qNein 2+b/pY7xjpThN0YZiZyuYKqOQyAxL/usRAwdi2KB2LfHgsGtSsXTIwfC0fEWcLy2qucQ 2li+zq9CYX1WSODMiG1qKhpxgwiuFzKLpUbnOoZLs7qMpSIGg6GmAeazK3Q95zCByKT1 iYsZBPuiBnIz8+JVI1XxKcZ3RXp0wU+pMXhnIOMMdlDl1BmDVtmfqxQqURtwRpRvglTc 4lrw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :in-reply-to:from:cc:content-language:references:to:subject :user-agent:mime-version:date:message-id:sender:dkim-signature; bh=ryeOLlvKjQ4PHBC65Nun7HyVScNqRFZ79Ubg87d+8Mc=; fh=Ky0gAfPXAB2TqCwl5srRivtK5/TaSmjGw+hDCTP7s+o=; b=STJdFJXet3zpqPeYGPDtXK3C6l0rzGHuF3tcMRXmkYkjGnlO9TUkYc8EbMQCJUTEba 1NXfZIEgbfgoKUYvRLdJ2i4ZzBaYlbLVGx036HVWtn2k6BLGczowiFcG+ODGFX60kPw9 SVumH4g5FHR4KcMIBtOUcS3IjPnLBVM447l9uqXo5vEKXEa10ZKSazT8WadnUh73lS2z JrbcYtXp4rBqiUhu8KCQo4NKqcumFY5UdFyoUNV0aNGc6RTKml7w5aj/92vnEyKzLjh3 W8yc9kSs7XjaPImZ9yeq++6rdRUlRmG8l+P1kyHquifD5Y6AhqnKijThrGSsjo9D7vd+ mW3Q==; darn=ilbers.de ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1727692597; x=1728297397; darn=ilbers.de; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from:cc :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=ryeOLlvKjQ4PHBC65Nun7HyVScNqRFZ79Ubg87d+8Mc=; b=gsee4QDPN1a/Fl6Af/tTo6JoQ7atYqcAI7ozVGi905hPQN82TRlBIBOhxbkyGU+/zE 3sCtN3gSd8IkfaBdBoPSXWzWzjLi4EJeXGV9T9GNwFTfJx+pwEx+Ofa7wsm8ul6EkQZ7 GFHEq5DZoZcDs00hbAY/q1b16j5fgrSxmIftTsDxh8amd0KX0ZErNg1RX0CXvBeBjhe0 IV/qrs9x6/z2vbFRZjWbR5bYs0a4H7ly0hkXgmhxUPGXWU2a0eVMc0HjxWKGas3aGdeT PABjELQ1KNH27vNLtncO5KHsZopdibJvXs++68f+LGI7mkg6SR0YJ3JKvWg1j9M0Ax4E ex9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727692597; x=1728297397; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :x-spam-checked-in-group:list-id:mailing-list:precedence :x-original-authentication-results:x-original-sender :content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=ryeOLlvKjQ4PHBC65Nun7HyVScNqRFZ79Ubg87d+8Mc=; b=cHT6rvnYjidZWj/1WpnT28ZPYsggitSNMduvTAaz9qx+Hv+XNVmPU93ki45R0/F0Hf ocCZ8ndSKdwXJ9QKaQKFsj12o8dccPDjATRr9KhIsI1AwBU20mjBQZkMsY43GytrwCw+ N/PIBo1sVIBmqFEQ+kNdRRe4sd6x4Co4sc3Y8cVzAlwQQrRd0/mNP4Q1NZKqwpZLVgmJ HT7hZiFrYU3/rHL6sH5w/igOlSe3WU5umUswVnKLFJE5VUzG5jU6mPYOPQDdGf3exUGA CLMiuEnGLRj2KUSudwVGQC5xBaAMDQ99ddUMQoVd3RK3MgtbzQmKusk7dpKrkyobFdrt /Hew== Sender: isar-users@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVgKU5Q9Lap87rN3dmZfXLuDwZvCIIs1WWsepAiUQ9JfLJ7UYowXB+nLaGQlkhFH22eIcxU@ilbers.de X-Gm-Message-State: AOJu0YxM2Zgfak6DkGXe8dOt9UrcATtDQU6dNk/rAcxfrZS+cjck3yOg bWDZTtUnsdCr8+KSlfQC/8BpJMx7m1a4INgkvKh/9JJ/DU5EbzUy X-Google-Smtp-Source: AGHT+IFoRZgZo3URaSFH/SQcvWyDJ5EhVayggWUy0a3NefwwIyZZKiA8mfkP7TFgdfw4ecPdeQ37ug== X-Received: by 2002:a05:6a00:4612:b0:713:e3f9:b58e with SMTP id d2e1a72fcca58-71b26044023mr20957664b3a.17.1727692596461; Mon, 30 Sep 2024 03:36:36 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6a00:2388:b0:714:3831:824f with SMTP id d2e1a72fcca58-71b18ba595dls2186735b3a.0.-pod-prod-04-us; Mon, 30 Sep 2024 03:36:35 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUf9mgInPdZbjLYepfh+UhtTHLMIEqvC+JoIuYiF++19tEZZYVzpo9M8bLyDeKef8C1mcHeBjVpz+cY@googlegroups.com X-Received: by 2002:a05:6a00:399e:b0:719:1f10:d1c9 with SMTP id d2e1a72fcca58-71b25effee7mr15844318b3a.2.1727692594703; Mon, 30 Sep 2024 03:36:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1727692594; cv=none; d=google.com; s=arc-20240605; b=AoxcpCAC2Y5Gr116JFESf2QVhK7bo+RC4tPyxoKjXzLaj7ONiHIlZYGV2/hn0WKCbw iHyx/wD0MtmRRjXdq5rjGcXWjmkaf8AVDiP5RZEfTpScOvYicg1AKhgdkqDqhO1PJw7D d61T+jzUu5C8e2M+Titmjf0jSFWxv0/UtKs/rqe18LD4/Qrt9I4zb+8fBHnf2W2TjdfY wPV2KsLalM7WrtVLiO9QhB9utu9MuU0YtaaCY9FffsBU4ikbtzu/ndTDQ7kym12bk65H MKtvEDd8YwSoGaaA8hnzBD7vI/sJGr+GuI2zwvLJw747KRUYidtmhlKKwkGelY8Detyq Tz1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id; bh=g9Q2P8zWDeaUAmS1wMvZ0N+OL5N5QvUVmfEg7pbMB5k=; fh=8bLOZgt3G720L0BETXrWmfiTT6IwZlZ9kfYzvoBy14E=; b=QJHbvFKZJDQlhb6QUSxmdO+NE57tipUxg9DBq45/UdXKxKMtqrdB9pfN71cEITCcUM 5ehDIqCoUUM58yDyk0Nh7DQE6MUM6oRsyat3hdVTonS1RX/qTu5zTtGFMptt5cYHzH42 KRwN+KFCcC7a2Xj9zoFXpE3dvsAhrwkniYAHmxSR3eST3AOJdJnrAPEqVfUURXTobeAH 7lO1SPmpDpbMmrCWrBwD1+C//nn3n7za7ZPZ5o6t3ILaq3gixxoxUHsVNHfoqTo5DrvR OhD5lFsf6wklWTLJczWawS+qRS3dMsmopKD/3wj/1QEnmNJPq9nHiu2BHsU0bTqtyhGh jb3A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-71b2653ff71si316710b3a.5.2024.09.30.03.36.33 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Sep 2024 03:36:34 -0700 (PDT) Received-SPF: pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Received: from [127.0.0.1] (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 48UAaTXV007189 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Sep 2024 12:36:30 +0200 Message-ID: <0ff24b5e-41a7-4aab-8a02-906774cf8af8@ilbers.de> Date: Mon, 30 Sep 2024 13:36:29 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Proposal for Adding OE/Yocto-Style Features Variables to Isar To: Christopher Larson , isar-users@googlegroups.com References: <27f2f225-d7c4-40dd-a4db-431eeb31cc52@siemens.com> Content-Language: en-US Cc: Jan Kiszka , Baurzhan Ismagulov From: Anton Mikanovich In-Reply-To: <27f2f225-d7c4-40dd-a4db-431eeb31cc52@siemens.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.6 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2, RCVD_IN_RP_CERTIFIED,RCVD_IN_RP_RNBL,RCVD_IN_RP_SAFE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-Original-Sender: amikan@ilbers.de X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Precedence: list Mailing-list: list isar-users@googlegroups.com; contact isar-users+owners@googlegroups.com List-ID: X-Spam-Checked-In-Group: isar-users@googlegroups.com X-Google-Group-Id: 914930254986 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-TUID: 6coqFb7wo/o7 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=20 > OE/Yocto-style features variables within the Isar project. Currently,=20 > Isar implements BASE_REPO_FEATURES and ROOTFS_FEATURES, which are=20 > quite useful. However, I believe that adding support for=20 > DISTRO_FEATURES, MACHINE_FEATURES, and possibly IMAGE_FEATURES would=20 > be worthwhile additions to consider. > > I want to preface this by acknowledging that my perspective is=20 > influenced by decades of experience with OpenEmbedded (OE) and=20 > OE-based products. I recognize that Isar has a different philosophy,=20 > favoring more direct approaches and fewer abstractions compared to OE. > > That said, I believe the value of these abstractions may justify the=20 > added complexity. It seems that many downstreams end up reinventing=20 > similar mechanisms for their own needs. For example, CIP adds=20 > INSTALL_WIRELESS_TOOLS, USE_CIP_KERNEL_CONFIG, and CIP_IMAGE_OPTIONS,=20 > the latter being a list of .inc files required by an image to allow=20 > for metadata reuse. Our usage at Siemens includes similar reinventions=20 > as well. > > Certainly, we could leverage ROOTFS_FEATURES for certain rootfs/image=20 > capabilities beyond the existing postprocessing in Isar. Establishing=20 > a convention for including optional rootfs/image capabilities could=20 > avoid metadata duplication, simplify managing development vs.=20 > production filesystems, and provide customization mechanisms for=20 > downstreams. > > Regarding DISTRO_FEATURES and MACHINE_FEATURES, the Yocto=20 > documentation covers them in general. The original intention was to=20 > allow for a mechanism similar to Gentoo=E2=80=99s USE flags, coupled with= OE=E2=80=99s=20 > three orthogonal axes of distro, machine, and image. The intersection=20 > of these would control the outcome, allowing any combination to be=20 > viable. This results in machine support that is not tightly coupled to=20 > distro capabilities or policy decisions, avoiding the pattern of each=20 > downstream copying and modifying both distro and machine in a single=20 > layer. This decoupling could prevent issues like machines installing=20 > packages such as expand-on-first-boot unnecessarily. > > In OE, the intersection of these features determines certain=20 > functionalities. A common example is hardware capabilities like WiFi=20 > or Bluetooth, where the distro expresses a desire to support certain=20 > functionalities. Only if both the distro and machine support it will=20 > the required packages be installed. > > Details would need to be worked out, even if it is determined that=20 > this provides more value than it adds in complexity. The core of the=20 > global features in OE is their intersection in packagegroup-base,=20 > which determines the default installed packages in images built from=20 > the ground up. While this doesn=E2=80=99t make sense in Isar with a Debia= n=20 > base image, there are still optional functionalities requiring package=20 > installation. Often, this requires more than just a single=20 > IMAGE_PREINSTALL line, so there=E2=80=99s value in having a simpler way t= o=20 > express a desire to support that functionality. Isar may not need to=20 > utilize this functionality directly, but it could be beneficial to=20 > provide it for downstream use. > > Downstreams can and do implement functionality like this if they want=20 > to, so I understand the argument for continuing this approach.=20 > However, I believe there is value in providing basic functions to=20 > utilize such capabilities and documented conventions for doing so=20 > consistently. > > I would love to hear what both Isar core developers and downstream=20 > developers think about the possibility of providing a mechanism for=20 > using variables like these. I believe that the ability to provide an=20 > easier customization mechanism and an abstraction to better separate=20 > concerns between the distro, machine, and images would be valuable. It=20 > would also ease rootfs customization based on desired system features=20 > (distro) and hardware capabilities (machine), if one uses these to=20 > adjust ROOTFS_FEATURES. > > I don=E2=80=99t believe the default behavior of OE=E2=80=99s IMAGE_FEATUR= ES, where=20 > package lists are defined in FEATURE_PACKAGES_, is worth including=20 > here. It=E2=80=99s not difficult for developers to manually implement pac= kage=20 > grouping using features if needed, and it=E2=80=99s often better to creat= e=20 > 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. --=20 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 e= mail 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.