From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6931066459248394240 X-Received: by 2002:a19:643:: with SMTP id 64mr1269507lfg.337.1614241562986; Thu, 25 Feb 2021 00:26:02 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:e86:: with SMTP id 128ls686220lfo.0.gmail; Thu, 25 Feb 2021 00:26:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJwyXMSx0QUj5DmykZLNxY15YPwlH/BFiNQCJd1kRG8yNas8CJlxzP2/7qLHYyrUPyLljerq X-Received: by 2002:a05:6512:524:: with SMTP id o4mr1366447lfc.544.1614241561808; Thu, 25 Feb 2021 00:26:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614241561; cv=none; d=google.com; s=arc-20160816; b=PyKLy8PjlPw01OlxxTxJaui77BKbh4pCk2NPiNKhrH3kh6VYPxYLXWMllLi43f6ZdZ 3dfMd6hn1rVTQ2vlVc1elRn32+vXRbovChoIYmbSeCCFXJW6jsD5SFUlUxjIKwUm6l1d gZfjalO9eWV8wKyoTUuY6Ck9dWTCPOB+LHSPqEIUhrdW21IPpj3AtJK+92YKmCw2oxJb Ut1Dgq0aTObq4+A0x7FQsC1anB9YePuVOUiIJXypjpwKwHjlr6o6ImAd/f1EyvZ7m6Mp oGFgoVt3h7XgMRm+eGLiNe5zxotfClhs4heF3wD8CYcJLeHIRkVbOvzc4J2EmZ7xe3I3 obtw== 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:from:references:to:subject; bh=NWI3m8yhdz6supcv7o/x4Y6Kt9xguGBQ+bBj0pGZYDE=; b=xiEMkhqhl9EHRTENfL1wrhCm5KU298AZHr9zoqkW7cj9/xCV3JPWF1l42ELcjVwODX UE00G0qAuspxvay4gCRzyNIELEAdCXxrwOZfrDJUx8j8NlFUXlfdyc4j+me8Sp5tpBIV 9+MyfoGSuhWCNfGGn1cWT4tToN1r4PD/gJTwis2Ltek8kxjYa9ypTjrA48YozE0e5IwV JtCicg3cIoRfMvZDzWyL8qIQDEaYG7EF4YezjeW0Zh+nxr/bJA4B6e+ve9quT6lz7JgN TWJ+RiOVzYv55UsVEHEboC4nwH8Gktfcgq+lr1ozcAJCo9ouEDHDiWwryPG5mukN2eWI fqlg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id m17si185440lfg.0.2021.02.25.00.26.01 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Feb 2021 00:26:01 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 11P8Q0gv013320 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Feb 2021 09:26:00 +0100 Received: from [167.87.36.30] ([167.87.36.30]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 11P8Kx6r009077; Thu, 25 Feb 2021 09:21:00 +0100 Subject: Re: [RFC PATCH 2/2] recipes-core: Add recipe for base-files To: "vijaikumar....@gmail.com" , isar-users References: <20210219195719.29037-1-Vijaikumar_Kanagarajan@mentor.com> <20210219195719.29037-3-Vijaikumar_Kanagarajan@mentor.com> <20210220092859.382eeb3a@md1za8fc.ad001.siemens.net> <20210224131256.14311847@md1za8fc.ad001.siemens.net> <807fb736-b3c2-4fcd-9e37-105e6b16827an@googlegroups.com> From: Jan Kiszka Message-ID: <67c6c7be-a1dc-0ffc-c8bc-943e4ec90868@siemens.com> Date: Thu, 25 Feb 2021 09:20:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <807fb736-b3c2-4fcd-9e37-105e6b16827an@googlegroups.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: i5lHMbM1p6eR On 25.02.21 06:08, vijaikumar....@gmail.com wrote: > > > On Thursday, February 25, 2021 at 9:27:51 AM UTC+5:30 > vijaikumar....@gmail.com wrote: > > On Wed, Feb 24, 2021 at 5:43 PM Henning Schild > wrote: > > > > Am Tue, 23 Feb 2021 14:08:29 +0530 > > schrieb vijai kumar : > > > > > On Sat, Feb 20, 2021 at 1:59 PM Henning Schild > > > wrote: > > > > > > > > Am Sat, 20 Feb 2021 01:27:19 +0530 > > > > schrieb Vijai Kumar K : > > > > > > > > > /etc/os-release is a symlink to /usr/lib/os-release and > belongs to > > > > > the base-files package. > > > > > > > > > > ISAR has been modifying the /etc/os-release during > postprocessing > > > > > to inject custom data onto it. > > > > > > > > > > Since this file belongs to base-files, an update/reinstall > of the > > > > > package would overwrite the file with the one provided by > > > > > base-files. > > > > > > > > To some degree such an update would be right to do so. The > BUILD_ID > > > > will for sure be invalidated, other custom fields might still be > > > > valid though. > > > > > > > > > Instead of modifying the contents of /etc/os-release during > > > > > post-processing, provide a modified base-files recipe in ISAR > > > > > which provides the similar changes in os-release. > > > > > > > > I am beginning to wonder if we have to write certain bits to > other > > > > files. Bits that need to go into /etc/os-release could be > appended > > > > with a hook > > > > See isar-disable-apt-cache, or we use the divert that Silvano > > > > proposed. > > > > > > I have not used hooks before, but looks like it might help in our > > > case. > > > > > > > > > > > > Signed-off-by: Vijai Kumar K > > > > > --- > > > > > .../recipes-core/images/isar-image-base.bb > | 2 + > > > > > meta/classes/image-postproc-extension.bbclass | 40 > -------------- > > > > > meta/classes/image.bbclass | 20 ------- > > > > > meta/recipes-core/base-files/base-files.bb > | 6 ++ > > > > > meta/recipes-core/base-files/base-files.inc | 55 > > > > > +++++++++++++++++++ 5 files changed, 63 insertions(+), 60 > > > > > deletions(-) create mode 100644 > > > > > meta/recipes-core/base-files/base-files.bb > create mode 100644 > > > > > meta/recipes-core/base-files/base-files.inc > > > > > > > > > > diff --git > a/meta-isar/recipes-core/images/isar-image-base.bb > > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > index > > > > > b381d85..4aa7e66 100644 --- > > > > > a/meta-isar/recipes-core/images/isar-image-base.bb > +++ > > > > > b/meta-isar/recipes-core/images/isar-image-base.bb > @@ -11,3 +11,5 > > > > > @@ LIC_FILES_CHKSUM = > > > > > > "file://${LAYERDIR_core}/licenses/COPYING.GPLv2;md5=751419260 PV = > > > > > "1.0" inherit image > > > > > + > > > > > +IMAGE_INSTALL += "base-files" > > > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > > > b/meta/classes/image-postproc-extension.bbclass index > > > > > 3f00c21..22c6a95 100644 --- > > > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > > > b/meta/classes/image-postproc-extension.bbclass @@ -1,38 > +1,6 @@ > > > > > # This software is a part of ISAR. > > > > > # Copyright (C) Siemens AG, 2019 > > > > > > > > > > -update_etc_os_release() { > > > > > - OS_RELEASE_BUILD_ID="" > > > > > - OS_RELEASE_VARIANT="" > > > > > - OS_RELEASE_VARIANT_VERSION="" > > > > > - while true; do > > > > > - case "$1" in > > > > > - --build-id) OS_RELEASE_BUILD_ID=$2; shift ;; > > > > > - --variant) OS_RELEASE_VARIANT=$2; shift ;; > > > > > - --version) OS_RELEASE_VARIANT_VERSION=$2; shift ;; > > > > > - -*) bbfatal "$0: invalid option specified: $1" ;; > > > > > - *) break ;; > > > > > - esac > > > > > - shift > > > > > - done > > > > > - > > > > > - if [ -n "${OS_RELEASE_BUILD_ID}" ]; then > > > > > - sudo sed -i '/^BUILD_ID=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > - if [ -n "${OS_RELEASE_VARIANT}" ]; then > > > > > - sudo sed -i '/^VARIANT=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > - if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > > > - sudo sed -i '/^ISAR_IMAGE_VERSION=.*/d' > > > > > '${IMAGE_ROOTFS}/etc/os-release' > > > > > - echo "VARIANT_VERSION=\"${PV}\"" | \ > > > > > - sudo tee -a '${IMAGE_ROOTFS}/etc/os-release' > > > > > - fi > > > > > -} > > > > > > > > This is in the image for a good reason, it can not be part of a > > > > package, otherwise it would already be and we might not have that > > > > evil postprocess feature. > > > > > > > > Try a run, append a package to IMAGE_PREINSTALL, build again > > > > > > > > I kind of bet that BUILD_ID will be wrong and not show your new > > > > commit or "dirty" > > > > > > Yes, It is wrong. > > > > > > Since we definitely know that we are bringing in a variable > > > that changes everytime when there is a change to the source > code, we > > > could very well do do_prepare_build[nostamp]="1". > > > > > > That with some changes should solve this problem. > > > > It will mean that every change will trigger a full reinstall of the > > image, many changes do that, but it sounds bad. > > > > And the false-sharing between images and multiconfigs still remains. > > > > Try two images in one layer with differing DESCRIPTIONS and see what > > happens. That would be the simple case without even thinking mc > > So basically os-release varies based on the image built. With a > single package > like this, it is no longer possible. At anypoint we could have only > one version > of the package. > > > Basically we just considered each image to be a "derivative" . Which I > don't suppose > is the case, at least with upstream ISAR. >   > > > Then, again, it makes me wonder if os-release is an apt place for such > information. > We lose updatability with the other approach. We definitely leave one > file (/etc/os-release or /usr/lib/os-release) > outdated on a dist upgrade.  > So far, we did not consider os-release in package-based update scenarios (likely because all our updates were partition based - which doesn't mean package-based will not come one day as well). If we include package-based updates, os-release should be updated by a package as well. Our os-release modification (ISAR_RELEASE_CMD) is bound to an image. An image is not a package, but we could make it depend on an image-specific package carrying or generating that os-release data. That package should definitely NOT be base-files. We need to divert that file and keep it under our control. Obviously, if the user decides to do a an upgrade of the Debian version on the device without pulling a new image version package, things will really divert - but that is no reasonable use case IMHO. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux