From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7012879449257410560 X-Received: by 2002:a17:906:6547:: with SMTP id u7mr34360455ejn.544.1637242881159; Thu, 18 Nov 2021 05:41:21 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:907:960d:: with SMTP id gb13ls1468297ejc.11.gmail; Thu, 18 Nov 2021 05:41:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJw/XDvh/z1XNnYpWTG2R+mSC94DD9axHoX/JtCVvf2SUQ7OOX/gqJRmMYBItdTxn4TkZFvq X-Received: by 2002:a17:907:d94:: with SMTP id go20mr34619299ejc.78.1637242880223; Thu, 18 Nov 2021 05:41:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637242880; cv=none; d=google.com; s=arc-20160816; b=H1mnOmSpp1MgbYbV8P/8UDpQk20orzHV/IztcK5Cf7wrHqJ8IkiTJweP80IlyjG3/Y 33M7WSwmR0ztZLzBcrYT9Lnq4IWPV77jdFAfbI3HwPhjVEIoO3idc9wrhLJwOnOiiKjg c33s0fooC+lAHSnaj+tdKZrjcB3DVToW1MkerHPJbDD3Wb3hmI+SunAxSZvrF0uziPZL UXg5MimBrLGqMrVEVy6jKRP+AvyQODi4RGngFXliRUSei95GAaEh9cXBVL+lAHtTmpKx GVxbfUKNnvDT4N/D9lP5Vqocp89M59/6zi+U7cEJ1LOW3v6e4UsSZZtSXfEZRgTSK7KO xVNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=J/OEceV/JV7KyGx5SWwYSck7BMzL9jo5jQ9h3qxR8Zs=; b=DlLZsCfz1HpvcYTF6PIK/fXpIb7VFvaFyeT439OinoIVdqxCx/bqmPicZpe5Ot7hNz J3vX3vG5zwGIxAZCs85m45yXpq0ZbpVoToR9TeuLDn4i0dFfhSu8k5hnBGMTEzrgRHaC bKcJjJmyoX5YZ+52+3t2h+m2mzmNyQrQOWp0fYW3mN5Dj4qU8v64Y936V/5YV6kx25NJ 7/MWBdvaw8Hmj12gdW7NBdFdiip+4RQOHysVfq9l8HUQrNUwgH7rRsFYt7AxBWOcaaZm 2fpV+F6tVmgddu87gTtbqub+UNQTUUVYuUGu7V23SIgRU+ZR6x7Zm5ybkqT9uTIw+H8w /GnA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id o19si162949edz.5.2021.11.18.05.41.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Nov 2021 05:41:20 -0800 (PST) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (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) with ESMTPSA id 1AIDfI9M016333 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 18 Nov 2021 14:41:19 +0100 Date: Thu, 18 Nov 2021 14:41:18 +0100 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH v2 0/5] Support multiple image types in one build Message-ID: <20211118134117.GB22100@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com References: <20210928071352.31382-1-ubely@ilbers.de> <20211005110856.3cb59475@md1za8fc.ad001.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211005110856.3cb59475@md1za8fc.ad001.siemens.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED 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-TUID: OrcbhpXPG/9x On Tue, Oct 05, 2021 at 11:08:56AM +0200, Henning Schild wrote: > In fact having exactly one image type and using multiconfig is already > very powerful. We have layers where we have custom image classes which > include existing ones and are set as the "main type". That is super > flexible already. No question :) . > I am not a fan of mc, but here we have a proposal that seems to want to > defeat mc and is lacking a clear motivation. At least i do not fully > understand why that change makes sense. The main point could be OE > alignment which might be good enough but not really too important. I guess we didn't communicate it clearly enough, this change doesn't remove the existing infrastructure -- the current way is still supported. v2 did touch the existing testcases -- in v3, we don't change them anymore and add a new case for testing the new functionality. > A simple array list is much less flexible. Imagine you want to have a > wic-img and an ext4 and your rootfs contains "expand-on-first-boot", > meaning wic will grow once on device ... while ext4 might need another > ROOTFS_EXTRA/_SIZE. In fact one will likely even have different > packages installed depending on the type. While packing the same rootfs > into multiple images will work it is much nicer to adapt the content to > the type. i.e. a container might need less of an init > system/kernel/initrd or filesystem support, a wic will maybe need > bootloader bits, and an ext4 will not need expand-on-first-boot (like > container as well) Thanks for the detailed example. For this use case, this approach is fine. The motivation for multiple image types is that BSP vendors want to provide all types of images with one image.bb and n machines, without permutations like mc:machine1-sd mc:machine1-tgz mc:machine2-sd mc:machine2-tgz. This change implements this use case. We'll send v3 soon. With kind regards, Baurzhan.