On Tuesday, April 21, 2020 at 8:49:43 PM UTC+2, Henning Schild wrote:On Tue, 21 Apr 2020 17:01:34 +0200
"[ext] Q. Gylstorff" <Quirin....@siemens.com> wrote:
> From: Quirin Gylstorff <quirin....@siemens.com>
>
> 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 <quirin....@siemens.com>
> ---
> meta/classes/image-postproc-extension.bbclass | 9 ++++++++-
> 1 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() {
> 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
> @@ -24,6 +26,11 @@ update_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'
Looking at
https://www.freedesktop.org/software/systemd/man/os-release.html
VARIANT_VERSION does not show up in the list of
"The following OS identifications parameters may be set using
os-release"
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.
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:
(1) The file is extensible? Awesome! I want a new field XYZ= in it! Sure,
it's extensible, and we are happy if distributions extend it. Please prefix
your keys with your distribution's name however.
(2) If you are working on a small/embedded distribution, or a legacy-free
distribution we encourage you to adopt only this file and not establish any
other per-distro release file.
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.
With that said, I am not saying that Isar should or should not add custom entries there. Just wanted to say that it is not forbidden
Ref: http://0pointer.de/blog/projects/os-release (link found from: http://0pointer.de/blog/projects/os-release)
Cedric
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
ISAR_RELEASE_CMD = "echo $(git -C ${LAYERDIR_isar-XXX} describe --long
--dirty --always) $(date --utc --rfc-3339=seconds)"
Henning
> + fi
> }
>
> ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure"
> @@ -43,7 +50,7 @@ ROOTFS_POSTPROCESS_COMMAND =+
> "image_postprocess_mark" image_postprocess_mark() {
> BUILD_ID=$(get_build_id)
> update_etc_os_release \
> - --build-id "${BUILD_ID}" --variant "${DESCRIPTION}"
> + --build-id "${BUILD_ID}" --variant "${DESCRIPTION}"
> --version "${PV}" }
>
> ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"