From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6901194598360547328 X-Received: by 2002:adf:f8d2:: with SMTP id f18mr3224231wrq.379.1606914016583; Wed, 02 Dec 2020 05:00:16 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:aa87:: with SMTP id h7ls2363705wrc.2.gmail; Wed, 02 Dec 2020 05:00:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJzfqpG4s7bAhM6nC6QVU6wRyGIIUHWeSW4d3lWLDYY5mSUkhPcEZrdO5VliQAfQmvOl+5nH X-Received: by 2002:a5d:4610:: with SMTP id t16mr3310594wrq.391.1606914015740; Wed, 02 Dec 2020 05:00:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606914015; cv=none; d=google.com; s=arc-20160816; b=LsGfkNLLdwXJpW1+Kik15W9MGx50Fl1ZmiwSuqI8ynGGcOcA+0uaaAKClb2j2d8IUX t8Tr50VtmvdB3Qog/nTaCvPP5CtjqP81LUZuxYyLcy58AMs2n4LSde/RpjTmULn3ne+b N5UGWHPaeazDNj6G2407IqXOAPGk+flGTNAGW9I0dzO4Igh5Ddo8KLeKwLGasZL6X+qO O6iLX+ApKZghamOMPKZCIl/TOTK7KJOcBeN5CD113BbhfYf70mCHPLkWS8wjehmqygYD XE25whRcnlcc9j1XqaZg+LljsHJNnJe4BIE/iU5ULPAE5AVs4hf2K8efQtmH6Jh0hTsF AHXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:organization:from:references:cc:to :subject; bh=GxnvZseMW0TC2tTnf1LUtkgTaqCw8LkHrZpDYidh5H8=; b=FZis2IjZpQN7bhREIkYa/njaKNUy6kf2WeczkxEv74McCHbHaQYZOF7Lovnhx1AHCS FI9o90d7zrOi9XoANEPvBfQrxpzIuybisRLc/Ty5Z+mwMW8hNoaGwVjzdQEp0tpCz5gH 9ACVSe+PfHEWcU4KqhSnUqIz1zw/bUMed4zi30DSl/O2eUPqecW9uzbKMlAXA18nuOF5 ZRP3pM4Jnv5bZBfvoFeWp8M2UrSLEroQIRogQdYhHP2r9vAYYSF92GTGeIYAaSnS4xV9 z0cvoA1gFjH6oJYtkuhnhAXyVJvq5xWNPT2ND5bt2rbRraqsZ+K7QHPz9cVfGw6Xcap1 QU1A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.9]) by gmr-mx.google.com with ESMTPS id x12si84693wmk.1.2020.12.02.05.00.15 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 05:00:15 -0800 (PST) Received-SPF: neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) client-ip=212.18.0.9; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4CmJwb3202z1qt4X; Wed, 2 Dec 2020 14:00:15 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4CmJwb2jjRz1r2w4; Wed, 2 Dec 2020 14:00:15 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id 5A8ZVnouYivt; Wed, 2 Dec 2020 14:00:13 +0100 (CET) X-Auth-Info: rZACRI0W3B9R3x7Oa1LoH7b0djDA3IPhUvvbNAHkpTg= Received: from [10.88.0.186] (dslb-084-056-254-149.084.056.pools.vodafone-ip.de [84.56.254.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Wed, 2 Dec 2020 14:00:13 +0100 (CET) Subject: Re: [RFC] Image templates To: Cedric Hombourger , isar-users@googlegroups.com Cc: joe_macdonald@mentor.com References: <6bf9a786-51b8-2430-90f5-2857746d003f@mentor.com> From: Claudius Heine Organization: Denx Software Engineering Message-ID: Date: Wed, 2 Dec 2020 14:00:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <6bf9a786-51b8-2430-90f5-2857746d003f@mentor.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 9qPujmLFj6s4 Hi Cedric, On 2020-12-01 08:59, Cedric Hombourger wrote: > Image Templates for ISAR > ======================== > > Introduction > ------------ > > Embedded System projects may have multiple teams working at different > levels. It is not uncommon to have groups creating a "base platform" > which is handed over to product teams to customize further. > Thanks to ISAR leveraging bitbake, image recipes from a base layer may > be easily extended by product layers but also with its ability to > produce and use a `base-apt` instead of upstream package feeds. > This workflow functions well in many cases, it may not be optimal for > application teams. Such teams are typically receiving a base platform > release that is likely to be left untouched for weeks. > Creating a product image for those teams is sometimes as easy as adding > a few packages. > > In such cases, it may be desirable to have a mechanism for ISAR to > construct product images starting from the base platform root > file-system instead of ISAR's bootstrap root file-system. We will refer > to these base platform root file-systems as _Template Images_. In principle I understand your requirement, however I don't think Isar (and possible Debian) is the right base for this. What you probably require is some sort of functional and non-destructive root-fs build approach to root file system, that lets you arbitrarily cache and distribute each stage of the root fs build. Generating and reusing the 'base-apt' repository is much easier than it would be for root file systems. Also stuff like docker solves only a small part of that solution. You will probably have to build a new system inspired by stuff like the bazel build system[1], and nixox[2] or guixos[3] and maybe even stuff like ostree [4]. The rest of what you describe sounds like they would try to shoehorn this into the existing isar build process and then trying to explicitly fix just some of the many future issues you will run into, instead of actually designing something that is actually able to deal with all those issues in a generic way. Personally, I would be interested in such a new system, but that will take serious dedication to design and implement it properly. Changing that now in Isar will probably break a lot of assumptions and therefore limit its usefulness. This suggestions reminds me a bit as the eSDK of OE, where I still couldn't really find a use for and from my experience creates more issues than it actually solves. regards, Claudius [1] https://www.bazel.build/ [2] https://nixos.org/ [3] https://guix.gnu.org/ [4] https://ostreedev.github.io/ostree/introduction/