From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6931066459248394240 X-Received: by 2002:a5d:6342:: with SMTP id b2mr14414099wrw.421.1614584410595; Sun, 28 Feb 2021 23:40:10 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:4ecf:: with SMTP id s15ls5340450wrv.1.gmail; Sun, 28 Feb 2021 23:40:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJwtaKOj4NmJXeTzqJO5FLm4vwil2F07ACS28fM3fpMaukr7JFe40JoxkwdapWPYM9MbbJ8u X-Received: by 2002:a5d:5405:: with SMTP id g5mr15585084wrv.406.1614584409731; Sun, 28 Feb 2021 23:40:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614584409; cv=none; d=google.com; s=arc-20160816; b=rTmgjEXQKD7RLPGoLeF/O6rI0YEtfFYa6B29Z01BdJj4LK7Gg147i3cnXf52gn03uu 2e9T9gasZYq9xj5sXxL/1mc74cyrqE4KNi4MbctMP5GoAdk6SAB0B68+yXYULP+mtbbv caxyY1uZ4CO8th8jdhksOiS12FnYDFfK3q99m4Y96mDx3FNavprXQrF0I0Bw7EJirbRG m+UoGhHnWo10LRB9WgQjrJ2w0xCr89HRWZtm5Tcb4hwo3ZlO8ixB+FwB8n4SFYvpG3mx LvoKmW6DO9pTEYQ2msT5jXGVAKBGYrBrGzS1bkrAHbQCMLIrkYDQbW8UGIGvLGb0ygwk WDKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=AtxOCgu9HzEC5urhXmboS1CcKQP22dGNzJfh72mlQtM=; b=eK0SN9EbQa4pxQeJz4p2eAwljqOuTtuKAs8KTqkic+L17z+HEBAZ2aDxoE86ozmO+S qDZm6a834nW0cfWFQlADwjlF+12X7lKuneSkqs0pM0kpafiSowCm+iEMms/T4fJ7t4s7 8WdkGvg8v2vyY4YnesBdIXDGBuL5xybU1UrOyqGLU70zyW1IDYMbb8oVDi2obCNujhhg aBEgDP411OBir/c+y8CwaeTRDpFcKxz5x0N6Vpl1vqT/EIDr0D0lSEZkNy70dNzCZRdv pX/3fHNCcZ/+/cjd3FM14t01nNax7DT+zswu50neJXldMcdRDi8mNBjpBGwQ70vjm1V8 sT4w== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@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 t9si281139wmj.2.2021.02.28.23.40.09 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Feb 2021 23:40:09 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 1217e8Wt014123 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 1 Mar 2021 08:40:08 +0100 Received: from md1za8fc.ad001.siemens.net ([167.87.44.113]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 1217Z8Dw029561; Mon, 1 Mar 2021 08:35:08 +0100 Date: Mon, 1 Mar 2021 08:35:07 +0100 From: Henning Schild To: "vijaikumar....@gmail.com" Cc: isar-users Subject: Re: [RFC PATCH 2/2] recipes-core: Add recipe for base-files Message-ID: <20210301083507.0e76b3e2@md1za8fc.ad001.siemens.net> In-Reply-To: <7a79ee87-6838-4f39-b69f-cc5450746bdbn@googlegroups.com> 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> <8412117e-4fc1-4ef7-8d5c-69dfde46dfefn@googlegroups.com> <20210225173252.36d8e5ab@md1za8fc.ad001.siemens.net> <7a79ee87-6838-4f39-b69f-cc5450746bdbn@googlegroups.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 8wNFOy40mmuX Am Sun, 28 Feb 2021 21:07:05 -0800 (PST) schrieb "vijaikumar....@gmail.com" : > On Thursday, February 25, 2021 at 10:07:55 PM UTC+5:30 Henning Schild > wrote: > > > Am Thu, 25 Feb 2021 01:06:16 -0800 (PST) > > schrieb "vijaikumar....@gmail.com" : > > > > > On Thursday, February 25, 2021 at 1:56:02 PM UTC+5:30 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. > > > > > > I am not quite sure if I get all that. We are now talking about a > > > new file in a > > > new package that depends on image recipe and have it diverted? So > > > that package would not be in the final image. But incase you need > > > to upgrade you would > > > make sure that the package is pulled by making it depend on a > > > specific base-files > > > package. When base-files upgrades the package would be upgraded > > > to? > > > > My suggestion is to not package that, just like we used to. We just > > put our stuff in a file via the image postinst. We write a package > > to "reserve" that file name against collision, that file will be > > empty in the package, but the hook and its script will live there. > > > > Say we had a package isar-base-files that would contain > > /etc/isar-release and /etc/apt/...hook.conf -> /usr/bin/merger.sh > > > > merger.sh: trigger on every base-files update > > for key in isar-release and key starts with "OS_": > > if key in os-release: > > update > > else > > append > > > > Now we might write DESCRIPTION to /etc/os-release and isar-release > > and BUILD_ID just to os-release ... because the latter is > > invalidated with any sort of live update. > > And yes you can use that to give Debian another name and that will > > survive updates ... because branding is very important! > > > > Henning > > > > > Thanks for the pointer Henning. I will try this implementation out. I > hope no one else is working on this approach. I do not think anyone else is currently working on that. And i hope it can work like i described. One thing seems pretty certain ... it is a very bad idea to "brand" debian. Modifications to that file should probably be kept to an absolute minimum. Additional stuff should probably go into additional files. Just to keep that in mind, because the projects you work on seem to have a strong desire on branding. That should be questioned instead of implemented. The initial idea to go for /etc/os-release was limited to two variables and "no updates with apt". regards, Henning > > > > Thanks, > > > Vijai Kumar K > > > > > > > > > > Jan > > > > > > > > -- > > > > Siemens AG, T RDA IOT > > > > Corporate Competence Center Embedded Linux > > > > > > > > > > > >