From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6815578895823142912 X-Received: by 2002:a7b:c181:: with SMTP id y1mr10540137wmi.83.1587552690069; Wed, 22 Apr 2020 03:51:30 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:224f:: with SMTP id a15ls1844675wmm.3.gmail; Wed, 22 Apr 2020 03:51:29 -0700 (PDT) X-Google-Smtp-Source: APiQypLCj6JRaezHyRHwSUSjSD8He7+/0ymxfaAsMfZLzbPUNG0DPFx7G24j4iXE/GHPkrfAg2bi X-Received: by 2002:a7b:ce88:: with SMTP id q8mr10532908wmj.161.1587552689475; Wed, 22 Apr 2020 03:51:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587552689; cv=none; d=google.com; s=arc-20160816; b=JlkXhVJJkJZVAJt3kFWIB0rdLaa+1UXdn310FsR7FHr8pd5Es9M0GERPeY7lmvlZE1 upNUhs8LTKj6/F65JcXAE/vGDWbTIpbVOYn66Hd98WrOQGNv1RUl3Y8ajTp8ngHutF5h KJ17L+pXXXvmm7FKgqaZW85EpdrGT0rJQAfK500smIpp1TUmMc3pZCxdxJwkktdDXatO i9Owfma8LxV4O0XwXv1G9GCQQc4U/PX8UFx8Bm63LdmqRVAZEu6dEelGVSjQE6y7xsa+ jGVpEkPy88VU3WM2jGxHCSMLtJucnS3noHbsh8sv3v/IiFuum3O2zzNqL1WP9Ki9E+cY xtQQ== 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=tqrZy0QFxrzeQBhN0y7jIC/MHHKDW3JfsBbM6zuaWxA=; b=CekVrVtohNQdvwD3NMygdoT/PwBrCA6UD+nQ/DfXeG41NXNiCVsd17tcNI0/9vpl6B U5y6ltjObRWDEMy2FcyPvuo1m39gxCmi5KeF4R4do6hwp2q+1bHhbjSDeQsqMfba6bf/ GBkd/r6cjYvzjAi45V7gvKmoccmlq1k9Glx/3tqplZGH6g2hkJTVLYeus3IP9PKQUsfs QbSNlpcrdPxdg6WOLnp6JguHjgYKbPmttIL7GP/mDUe7TKFTr2fFtT2HcyfcXkGM7H0G jsONYpHYQMLUa1qCLqfHS1aJAmsuJy9iC9xAvkp0HYGjaFOA+SYn9spSwgPIxdtMwBuX kpnA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 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 thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id 70si2224wrk.0.2020.04.22.03.51.29 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2020 03:51:29 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@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 thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 03MApTw0011850 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2020 12:51:29 +0200 Received: from md1za8fc.ad001.siemens.net ([167.87.23.203]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 03MApSEp015773; Wed, 22 Apr 2020 12:51:28 +0200 Date: Wed, 22 Apr 2020 12:51:27 +0200 From: Henning Schild To: Gylstorff Quirin Cc: , Cedric Hombourger Subject: Re: [PATCH v2] classes/image-postproc: Add image version Message-ID: <20200422125127.497d2628@md1za8fc.ad001.siemens.net> In-Reply-To: <04aa3786-daa7-dbe0-026c-7b69be75e225@siemens.com> References: <20200421150134.30325-1-Quirin.Gylstorff@siemens.com> <20200421204939.0ddaa020@md1za8fc.ad001.siemens.net> <04aa3786-daa7-dbe0-026c-7b69be75e225@siemens.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: Qfm0kJtL1Fz5 On Wed, 22 Apr 2020 10:36:32 +0200 Gylstorff Quirin wrote: > On 4/21/20 9:28 PM, cedric_hombourger@mentor.com wrote: > >=20 > >=20 > > On Tuesday, April 21, 2020 at 8:49:43 PM UTC+2, Henning Schild > > wrote: > >=20 > > On Tue, 21 Apr 2020 17:01:34 +0200 > > "[ext] Q. Gylstorff" > > > wrote:=20 > > > From: Quirin Gylstorff > > > > > > > Add the image version as additional identifier to > > > /etc/os-release. This allows in a update scenario an easier > > > identification of the the currently used image. > > > > > > Signed-off-by: Quirin Gylstorff > > =20 > > > --- > > > =C2=A0meta/classes/image-postproc-extension.bbclass | 9 ++++++++- > > > =C2=A01 file changed, 8 insertions(+), 1 deletion(-) > > > > > > diff --git a/meta/classes/image-postproc-extension.bbclass > > > b/meta/classes/image-postproc-extension.bbclass index > > > 7280202..1091fa4 100644 --- > > > a/meta/classes/image-postproc-extension.bbclass +++ > > > b/meta/classes/image-postproc-extension.bbclass @@ -4,10 > > > +4,12 @@ update_etc_os_release() { > > > =C2=A0 =C2=A0 =C2=A0OS_RELEASE_BUILD_ID=3D"" > > > =C2=A0 =C2=A0 =C2=A0OS_RELEASE_VARIANT=3D"" > > > + =C2=A0 =C2=A0OS_RELEASE_VARIANT_VERSION=3D"" > > > =C2=A0 =C2=A0 =C2=A0while true; do > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case "$1" in > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--build-id) OS_RELEASE_BUILD_I= D=3D$2; shift ;; > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--variant) OS_RELEASE_VARIANT= =3D$2; shift ;; > > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0--version) OS_RELEASE_VARIANT_VERSI= ON=3D$2; shift ;; > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-*) bbfatal "$0: invalid optio= n specified: $1" ;; > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*) break ;; > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0esac > > > @@ -24,6 +26,11 @@ update_etc_os_release() { > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0echo "VARIANT=3D\"${OS_RELEASE= _VARIANT}\"" | \ > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sudo tee -a '${I= MAGE_ROOTFS}/etc/os-release' > > > =C2=A0 =C2=A0 =C2=A0fi > > > + =C2=A0 =C2=A0if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then > > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0sudo sed -i '/^ISAR_IMAGE_VERSION= =3D.*/d' > > > '${IMAGE_ROOTFS}/etc/os-release' > > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0echo "VARIANT_VERSION=3D\"${PV}\"" = | \ > > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sudo tee -a '${IMAGE_= ROOTFS}/etc/os-release' =20 > >=20 > > Looking at > > https://www.freedesktop.org/software/systemd/man/os-release.html > > > >=20 > > VARIANT_VERSION does not show up in the list of > > "The following OS identifications parameters may be set using > > os-release" > >=20 > > So i would conclude we may not use it. I would suggest either > > finding a variable that we may use and debian does not use yet. > >=20 > >=20 > > for everyone's benefits, Henning and I were discussing this > > offline. from my perspective, the freedesktop folks aren't that > > rigid. 2 quotes from them: > >=20 > > (1) The file is extensible? Awesome! I want a new field XYZ=3D in it!=20 > > Sure, it's extensible, and we are happy if distributions extend it.=20 > > Please prefix your keys with your distribution's name however. > >=20 > > (2) If you are working on a small/embedded distribution, or a=20 > > legacy-free distribution we encourage you to adopt only this file > > and not establish any other per-distro release file. > >=20 > > I am guilty of adding custom fields in the Debian-based distro we > > are producing over here. I had missed the recommendation to prefix > > new keys with the name of the distro. That's a good thing to do for > > sure. > >=20 > > With that said, I am not saying that Isar should or should not add=20 > > custom entries there. Just wanted to say that it is not forbidden > > Ref: http://0pointer.de/blog/projects/os-release (link found from:=20 > > http://0pointer.de/blog/projects/os-release) > >=20 > > Cedric =20 >=20 > I see that as a human readable version identifier for an > image. Not every one has git at hand ;-).=20 The CMD can be anything, use "hg" or "echo 42". > We can add our own ids with=20 > ISAR_ in front of it, if it is better > that way as written in [1]: >=20 > `Operating system vendors may extend the file format and introduce > new fields. It is highly recommended to prefix new fields with an OS=20 > specific name in order to avoid name clashes. Applications reading > this file must ignore unknown fields. Example:=20 > "DEBIAN_BTS=3D"debbugs://bugs.debian.org/""` >=20 > As the only hard requirement regarding this file is that application > ignore unknown items. >=20 > [1]: https://www.freedesktop.org/software/systemd/man/os-release.html True, my interpretation of the "opposite" of "may" might be too harsh when i suggest that opposite to be "must not". I just wanted to raise awareness that this is a "standardized" file and care needs to be taken. There probably are a lot of scripts out there, that "source" the file and could get very confused when they loose their own variables or env that way, because the file is full of unexpected stuff. And yes, they technically "must ignore" ... still another reason to be careful. Henning > Quirin >=20 > >=20 > >=20 > > Or the layer with the requirement looks at BUILD_ID and sets a > > custom ISAR_RELEASE_CMD to inject their clue. > > Here is an example where people decided to include the date of > > a build > >=20 > > ISAR_RELEASE_CMD =3D "echo $(git -C ${LAYERDIR_isar-XXX} describe > > --long --dirty --always) $(date --utc --rfc-3339=3Dseconds)" > >=20 > > Henning > > =20 > > > + =C2=A0 =C2=A0fi > > > =C2=A0} > > > > > > =C2=A0ROOTFS_POSTPROCESS_COMMAND =3D+ "image_postprocess_configu= re" > > > @@ -43,7 +50,7 @@ ROOTFS_POSTPROCESS_COMMAND =3D+ > > > "image_postprocess_mark" image_postprocess_mark() { > > > =C2=A0 =C2=A0 =C2=A0BUILD_ID=3D$(get_build_id) > > > =C2=A0 =C2=A0 =C2=A0update_etc_os_release \ > > > - =C2=A0 =C2=A0 =C2=A0 =C2=A0--build-id "${BUILD_ID}" --variant = "${DESCRIPTION}" > > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0--build-id "${BUILD_ID}" --variant = "${DESCRIPTION}" > > > --version "${PV}" } > > > > > > =C2=A0ROOTFS_POSTPROCESS_COMMAND =3D+ > > > "image_postprocess_machine_id" =20 > >=20 > > --=20 > > You received this message because you are subscribed to the Google=20 > > Groups "isar-users" group. > > To unsubscribe from this group and stop receiving emails from it, > > send an email to isar-users+unsubscribe@googlegroups.com=20 > > . > > To view this discussion on the web visit=20 > > https://groups.google.com/d/msgid/isar-users/f8bdcad7-3efe-485a-85ee-fd= a69c2d616f%40googlegroups.com=20 > > . > > =20 >=20