From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6931066459248394240 X-Received: by 2002:a2e:1504:: with SMTP id s4mr1047280ljd.346.1614242746240; Thu, 25 Feb 2021 00:45:46 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:ac46:: with SMTP id r6ls727586lfc.2.gmail; Thu, 25 Feb 2021 00:45:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJxu5DIHCbMSTQBYg84+TBKSVgOsQ1LgCJdYUfBm2b1ptWpz2ReaOr9rkiCO8P7Idq51Kaeo X-Received: by 2002:a19:4192:: with SMTP id o140mr1365159lfa.427.1614242745111; Thu, 25 Feb 2021 00:45:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614242745; cv=none; d=google.com; s=arc-20160816; b=wlbX8pCMBvCZOYHghgFCo7Wo00Z064hLEdc44qkfoxNijbpGj5ZOhW3usAUA4TRDo2 1wK1cBMpqYZV4o1Q3/eqffhm+Y01MhLSz4sNKvgntmrsKcLK6RweorHba4tInwhco8im KWdk/X0bQ7T2hqJnZ8gLpdY/LHKfc+8k4vGK0AUwwgRyqUkN39hHikYGKpxGX+byu4OA IFDriNtleEMKSWYrlsUgWp0FEePrWENaeqIPgLAaaQp3Fa3CZmfVBu8kz6ci7SvPt1HE 8CajCfgYa64vIeuG3ML8K9pL8yvwR0rNYUqutK+VFVWc11PIKKv7B9r4rQjEEYyEigNO mVoA== 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:references:to:from:subject; bh=ByKSDGOMYWRDlrVs8k676LD/4wnwUUbIc8qLAQDdYpQ=; b=vHmBJnbU8PGB1YCIMnCybrRhz6NxaSETJoctkZJjZEAUfQn+CgC7Mz3syGHFetNyY+ OzeuDzJ7sOquxcfgZ6XFaO/nrMtY5lD4QvVvLDSOu5hZWdZg4rq0hnugl2iSVsS7YLPy zsRH0J0ejmJ3EBbKvyGc0BQ6TAJG9k9HGGWvxQ2FOz1dw4kqUYY4WzwBy4ZcRzcgxt4n sZMJvEBlu7w5qmtKUcMiHF7Y2Kgdhq1TQ5Q5SlLDpwn0WXDyZdPceIUuZfEGyTG/b3I1 EJavSO393EymjLEARK4GPlujg4JX6E56/pMFIXilvB2+eQjafPJztSxpWk9gKgVVpqDb pw1A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id s5si241940ljg.7.2021.02.25.00.45.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Feb 2021 00:45:44 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 11P8jhkE015336 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Feb 2021 09:45:43 +0100 Received: from [167.87.36.30] ([167.87.36.30]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 11P8ehRN007141; Thu, 25 Feb 2021 09:40:43 +0100 Subject: Re: [RFC PATCH 2/2] recipes-core: Add recipe for base-files From: Jan Kiszka 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> <67c6c7be-a1dc-0ffc-c8bc-943e4ec90868@siemens.com> Message-ID: <2d9a1981-94e9-22ed-43f3-7a8d9f2a05f6@siemens.com> Date: Thu, 25 Feb 2021 09:40:43 +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: <67c6c7be-a1dc-0ffc-c8bc-943e4ec90868@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: twJGdi6TzanD On 25.02.21 09:20, Jan Kiszka wrote: > 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. > In fact, we could make our image-version package depend on the specific base-files version it diverted from. Then we would still encode the need to update both in lock-step, but without having to pointlessly recompile the base-files package. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux