[RFC PATCH 0/2] Custom base-files

[Vijai Kumar K]

This series introduced 2 patchsets.
P1 though could be a separate patchset, is clubbed with this series
since it is needed for P2.

This series removes the postprocessing logic that modifies /etc/os-release
to inject custom data into it. Instead, proposes a custom base-files
based approach to solve the problem.

The basic issue identified with the post-processing approach is that
the information put onto /etc/os-release will be overwritten by the
one provided by the base-files package on reinstall/upgrade.

For a history of this issue and relevant discussions please see [1]

[1]https://groups.google.com/g/isar-users/c/Jr3bTPumH-w

This might need some entry in user-manual and/or changelog. Will be
added after further testing and in the final version of the patchset.

Vijai Kumar K (2):
dpkg-base: Handle custom source directory in do_apt_fetch
recipes-core: Add recipe for base-files

.../recipes-core/images/isar-image-base.bb | 2 +
meta/classes/dpkg-base.bbclass | 7 ++-
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 +++++++++++++++++++
6 files changed, 69 insertions(+), 61 deletions(-)
create mode 100644 meta/recipes-core/base-files/base-files.bb
create mode 100644 meta/recipes-core/base-files/base-files.inc

--
2.17.1

[Vijai Kumar K]

With the current do_apt_fetch implementation, it is not possible to use
a custom source directory(${S}).

apt-get source by default extracts the contents of the debian source
into folder with name <pkg>_<version>.

Add provision for specifying a custom source directory.

Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com>
---
meta/classes/dpkg-base.bbclass | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/dpkg-base.bbclass b/meta/classes/dpkg-base.bbclass
index 5c7bddc..1b94b76 100644
--- a/meta/classes/dpkg-base.bbclass
+++ b/meta/classes/dpkg-base.bbclass
@@ -70,7 +70,12 @@ do_apt_fetch() {
sudo -E chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} \
sh -c 'mkdir -p /downloads/deb-src/"$1"/"$2" && cd /downloads/deb-src/"$1"/"$2" && apt-get -y --download-only --only-source source "$2"' my_script "${DISTRO}" "${uri}"
sudo -E chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} \
- sh -c 'cp /downloads/deb-src/"$1"/"$2"/* ${PP} && cd ${PP} && apt-get -y --only-source source "$2"' my_script "${DISTRO}" "${uri}"
+ sh -c ' \
+ dscfile="$(apt-get -y -qq --print-uris source "${2}" | cut -d " " -f2 | grep -E "*.dsc")"
+ cd ${PP}
+ cp /downloads/deb-src/"${1}"/"${2}"/* ${PP}
+ dpkg-source -x "${dscfile}" "${PPS}"' \
+ my_script "${DISTRO}" "${uri}"
done

dpkg_undo_mounts
--
2.17.1

[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.

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.

Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com>
---

.../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
-}
-
ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_configure"
image_postprocess_configure() {
# Configure root filesystem
@@ -45,14 +13,6 @@ image_postprocess_configure() {
fi
}

-ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_mark"
-
-image_postprocess_mark() {
- BUILD_ID=$(get_build_id)
- update_etc_os_release \
- --build-id "${BUILD_ID}" --variant "${DESCRIPTION}" --version "${PV}"
-}
-
ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_machine_id"
image_postprocess_machine_id() {
# systemd(1) takes care of recreating the machine-id on first boot
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index eddc444..d849175 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -49,9 +49,6 @@ SRC_URI += "${@ cfg_script(d) }"

DEPENDS += "${IMAGE_INSTALL}"

-ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags --dirty --match 'v[0-9].[0-9]*'"
-ISAR_RELEASE_CMD ?= "${ISAR_RELEASE_CMD_DEFAULT}"
-
image_do_mounts() {
sudo flock ${MOUNT_LOCKFILE} -c ' \
mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" "${BUILDROOT_WORK}"
@@ -91,23 +88,6 @@ def get_rootfs_size(d):

return base_size + rootfs_extra * 1024

-# here we call a command that should describe your whole build system,
-# this could be "git describe" or something similar.
-# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs to do something
-# completely different
-get_build_id() {
- if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] &&
- [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; then
- bbwarn "You are using external layers that will not be" \
- "considered in the build_id. Consider changing" \
- "ISAR_RELEASE_CMD."
- fi
- if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then
- bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty build_id."
- echo ""
- fi
-}
-
python set_image_size () {
rootfs_size = get_rootfs_size(d)
d.setVar('ROOTFS_SIZE', str(rootfs_size))
diff --git a/meta/recipes-core/base-files/base-files.bb b/meta/recipes-core/base-files/base-files.bb
new file mode 100644
index 0000000..d250fc5
--- /dev/null
+++ b/meta/recipes-core/base-files/base-files.bb
@@ -0,0 +1,6 @@
+# This software is a part of ISAR.
+# Copyright (c) Mentor, A Siemens Business, 2021
+#
+# SPDX-License-Identifier: MIT
+
+require base-files.inc
diff --git a/meta/recipes-core/base-files/base-files.inc b/meta/recipes-core/base-files/base-files.inc
new file mode 100644
index 0000000..68d0e3a
--- /dev/null
+++ b/meta/recipes-core/base-files/base-files.inc
@@ -0,0 +1,55 @@
+# This software is a part of ISAR.
+# Copyright (c) Mentor, A Siemens Business, 2021
+#
+# SPDX-License-Identifier: MIT
+
+inherit dpkg
+
+SRC_URI = "apt://${PN}"
+
+S="${WORKDIR}/${PN}"
+
+MAINTAINER = "isar-users <isar-...@googlegroups.com>"
+CHANGELOG_V = "<orig-version>+isar"
+
+ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags --dirty --match 'v[0-9].[0-9]*'"
+ISAR_RELEASE_CMD ?= "${ISAR_RELEASE_CMD_DEFAULT}"
+OS_RELEASE_VARIANT = "Isar target filesystem"
+OS_RELEASE_VARIANT_VERSION = "1.0"
+
+# here we call a command that should describe your whole build system,
+# this could be "git describe" or something similar.
+# set ISAR_RELEASE_CMD to customize, or override do_mark_rootfs to do something
+# completely different
+get_build_id() {
+ if [ $(echo ${BBLAYERS} | wc -w) -ne 2 ] &&
+ [ "${ISAR_RELEASE_CMD}" = "${ISAR_RELEASE_CMD_DEFAULT}" ]; then
+ bbwarn "You are using external layers that will not be" \
+ "considered in the build_id. Consider changing" \
+ "ISAR_RELEASE_CMD."
+ fi
+ if ! ( ${ISAR_RELEASE_CMD} ) 2>/dev/null; then
+ bbwarn "\"${ISAR_RELEASE_CMD}\" failed, returning empty build_id."
+ echo ""
+ fi
+}
+
+do_prepare_build() {
+ deb_add_changelog
+ OS_RELEASE_BUILD_ID=$(get_build_id)
+ if [ -n "${OS_RELEASE_BUILD_ID}" ]; then
+ sed -i '/^BUILD_ID=.*/d' '${S}/etc/os-release'
+ echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \
+ tee -a '${S}/etc/os-release'
+ fi
+ if [ -n "${OS_RELEASE_VARIANT}" ]; then
+ sed -i '/^VARIANT=.*/d' '${S}/etc/os-release'
+ echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \
+ tee -a '${S}/etc/os-release'
+ fi
+ if [ -n "${OS_RELEASE_VARIANT_VERSION}" ]; then
+ sed -i '/^VARIANT_VERSION=.*/d' '${S}/etc/os-release'
+ echo "VARIANT_VERSION=\"${OS_RELEASE_VARIANT_VERSION}\"" | \
+ tee -a '${S}/etc/os-release'
+ fi
+}
--
2.17.1

[Henning Schild]

Am Sat, 20 Feb 2021 01:27:18 +0530
schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>:

> With the current do_apt_fetch implementation, it is not possible to
> use a custom source directory(${S}).
>
> apt-get source by default extracts the contents of the debian source
> into folder with name <pkg>_<version>.
>
> Add provision for specifying a custom source directory.

I think this one is indeed worth being discussed seperately.

Could you go into detail why a custom S is required in the first place?
My guess is that we might not know PV and need to wait for that
apt-unpack to finish so we can find it in the changelog.

> Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com>
> ---
> meta/classes/dpkg-base.bbclass | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/dpkg-base.bbclass
> b/meta/classes/dpkg-base.bbclass index 5c7bddc..1b94b76 100644
> --- a/meta/classes/dpkg-base.bbclass
> +++ b/meta/classes/dpkg-base.bbclass
> @@ -70,7 +70,12 @@ do_apt_fetch() {
> sudo -E chroot --userspec=$( id -u ):$( id -g )
> ${BUILDCHROOT_DIR} \ sh -c 'mkdir -p /downloads/deb-src/"$1"/"$2" &&
> cd /downloads/deb-src/"$1"/"$2" && apt-get -y --download-only
> --only-source source "$2"' my_script "${DISTRO}" "${uri}" sudo -E
> chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} \
> - sh -c 'cp /downloads/deb-src/"$1"/"$2"/* ${PP} && cd
> ${PP} && apt-get -y --only-source source "$2"' my_script "${DISTRO}"
> "${uri}"
> + sh -c ' \
> + dscfile="$(apt-get -y -qq --print-uris source "${2}"
> | cut -d " " -f2 | grep -E "*.dsc")"
> + cd ${PP}
> + cp /downloads/deb-src/"${1}"/"${2}"/* ${PP}
> + dpkg-source -x "${dscfile}" "${PPS}"' \
> + my_script "${DISTRO}" "${uri}"

You removed the && chaining, please try a "false" in there, i guess
that sh might need a -e now

I wonder if we can just symlink debians choice to PPS, or mv, or even
"cp -a"
And make that a new task we call apt_unpack

Henning

> done
>
> dpkg_undo_mounts

[Henning Schild]

Am Sat, 20 Feb 2021 01:27:19 +0530

schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>:

> /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.

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"

Just one such package. We will need for for every single image we build
in the tree. There can be multiple, especially when multiconfig comes
into play, but even without.

Think of the internal layer you just helped with for a release, it
builds the product and the debug variant, which differ in their
DESCRIPTION and must not share that package.

I am afraid a package will not work. We would need a package per image.
And that package would need to rebuild every time the BUILD_ID changes.

But now you still have the problem that someone could install a more
recent "base-files" ... Might as well use preferences to pin it
forever, instead of forking it and giving it a number that will
hopefully never be smaller than the one from debian

Henning

[vijai kumar]

On Sat, Feb 20, 2021 at 1:47 PM Henning Schild
<henning...@siemens.com> wrote:
>
> Am Sat, 20 Feb 2021 01:27:18 +0530
> schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>:
>
> > With the current do_apt_fetch implementation, it is not possible to
> > use a custom source directory(${S}).
> >
> > apt-get source by default extracts the contents of the debian source
> > into folder with name <pkg>_<version>.
> >
> > Add provision for specifying a custom source directory.
>
> I think this one is indeed worth being discussed seperately.
>
> Could you go into detail why a custom S is required in the first place?
> My guess is that we might not know PV and need to wait for that
> apt-unpack to finish so we can find it in the changelog.

Exactly. In some cases we might not know PV, we might need to wait
for apt to see what version it is fetching. Change the APT sources and or
preferences and you might get a completely new version of the package.
We cannot effectively know ${S} for manipulating the source code from
the recipe.

Yes. Will add that in v2.

>
> I wonder if we can just symlink debians choice to PPS, or mv, or even
> "cp -a"

Wondering whether it brings in any added advantage?

> And make that a new task we call apt_unpack

I thought about this too. We could definitely have something like apt_unpack
that makes things clear. When I first started looking around, I didn't
expect the
unpacking to happen in fetch.

Thanks,
Vijai Kumar K

>
> Henning
>
> > done
> >
> > dpkg_undo_mounts
>
> --
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/20210220090734.60a591c2%40md1za8fc.ad001.siemens.net.

[Anton Mikanovich]

19.02.2021 22:57, Vijai Kumar K wrote:
> /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.
>
> 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.
>
> Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com>

Hello, base-files package failed to build for qemuarm64-focal target
during CI:

15:12:37    dh_strip
15:12:37 aarch64-linux-gnu-objcopy: Unable to recognise the format of
the input file `debian/base-files/usr/bin/locale-check'
15:12:37 dh_strip: error: aarch64-linux-gnu-objcopy --only-keep-debug
--compress-debug-sections debian/base-files/usr/bin/locale-check
debian/.debhelper/base-files/dbgsym-root/usr/lib/debug/.build-id/71/aa3df0a7e05817cb7e212513aeae7db21d8593.debug
returned exit code 1
15:12:37 dh_strip: error: Aborting due to earlier error
15:12:37 make: *** [debian/rules:15: binary] Error 25
15:12:37 dpkg-buildpackage: error: fakeroot debian/rules binary
subprocess returned exit status 2
15:12:37 WARNING: exit code 2 from a shell command.

Full log: http://ci.isar-build.org:8080/job/isar_am_devel_fast/89/console

--
Anton Mikanovich
Promwad Ltd.
External service provider of ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn, Germany
+49 (89) 122 67 24-0
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

[vijai kumar]

On Sat, Feb 20, 2021 at 1:59 PM Henning Schild
<henning...@siemens.com> wrote:
>
> Am Sat, 20 Feb 2021 01:27:19 +0530
> schrieb Vijai Kumar K <Vijaikumar_...@mentor.com>:
>
> > /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.

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.

Thanks,
Vijai Kumar K

> --
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/20210220092859.382eeb3a%40md1za8fc.ad001.siemens.net.

[vijaikumar....@gmail.com]

Thank you Anton, for quickly running this through our CI.  I will try to replicate the issue in my local build and will fix it in next version.

Best,

Vijai Kumar K

[vijaikumar....@gmail.com]

This seems to be like a qemu issue.

https://www.mail-archive.com/debian...@lists.debian.org/msg59230.html

We could work around it by setting ISAR_CROSS_COMPILE. But ubuntu base-files cross compilation is failing.

That needs to be fixed first. Maybe should raise an issue in ubuntu.

Thanks,

Vijai Kumar K

[Jan Kiszka]

Are we running qemu-user-static from bullseye here already? That is what
we do in kas-isar for a while.

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[vijaikumar....@gmail.com]

Just now tried in kas. It works as expected. Maybe we might need to update ISAR

docs to denote the need for the latest qemu? 

That leaves the cross-building issue.

Raised a bug report in ubuntu for that.

https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1916714

I will also see if I can send a patch for this. Till then we might need to disable

ISAR_CROSS_COMPILE for base-files for ubuntu.

Thanks,

Vijai Kumar K

 

[Henning Schild]

Am Wed, 24 Feb 2021 03:40:48 -0800 (PST)
schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>:

Nice to see those reports and doc updates coming out (vijai, please
send that doc patch)

But the general approach of this packages seems to be a dead end
https://groups.google.com/g/isar-users/c/maMS_p5Ep2o/m/lWSgTr7TAgAJ

Henning

[Henning Schild]

Am Tue, 23 Feb 2021 14:08:29 +0530
schrieb vijai kumar <vijaikumar....@gmail.com>:

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

Henning

[vijai kumar]

On Wed, Feb 24, 2021 at 5:43 PM Henning Schild

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.

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.

Thanks,
Vijai Kumar K

[vijaikumar....@gmail.com]

Basically we just considered each image to be a "derivative" . Which I don't suppose

is the case, at least with upstream ISAR.

[Henning Schild]

Am Thu, 25 Feb 2021 09:27:38 +0530

Exactly what i said earlier. We should use another file. And in case we
want to keep some information really in /etc/os-release we need to
write a hook to merge our bits in every single time apt owns it again.

[Jan Kiszka]

> <http://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

> <http://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

> <http://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
> <http://isar-image-base.bb>
> > > > > b/meta-isar/recipes-core/images/isar-image-base.bb
> <http://isar-image-base.bb> index
> > > > > b381d85..4aa7e66 100644 ---
> > > > > a/meta-isar/recipes-core/images/isar-image-base.bb
> <http://isar-image-base.bb> +++
> > > > > b/meta-isar/recipes-core/images/isar-image-base.bb
> <http://isar-image-base.bb> @@ -11,3 +11,5

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.

[vijaikumar....@gmail.com]

Then we are back to having something like /etc/isar_info.

[Jan Kiszka]

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.

[vijaikumar....@gmail.com]

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?

Thanks,

Vijai Kumar K

[Henning Schild]

Am Thu, 25 Feb 2021 01:06:16 -0800 (PST)
schrieb "vijaikumar....@gmail.com" <vijaikumar....@gmail.com>:

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

[vijaikumar....@gmail.com]

Thanks for the pointer Henning. I will try this implementation out. I hope no one else is working on this approach.

[Henning Schild]

Am Sun, 28 Feb 2021 21:07:05 -0800 (PST)

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

[vijaikumar....@gmail.com]

I am not sure why you feel it is a bad idea, there has always been a lot of derivatives of Debian. And ISAR as

a tool could provide an example on how to do it. Branding is another discussion, and irrespective of that, we

are just trying to find a way to add additional fields to /etc/os-release and fix this upgrade issue :) Having custom

base-files was one such approach(had limitations). Since you have an entirely new suggestion, I would like to try that out to see

how it becomes a candidate to solve the problem in hand. :)

Thanks,

Vijai Kumar K

[Henning Schild]

Can we please get this one stand-alone on the fast-path? Just ran into
exactly the problem and now have to work around.

regards,
Henning

Am Mon, 22 Feb 2021 12:41:40 +0530
schrieb vijai kumar <vijaikumar....@gmail.com>:

[Kanagarajan, Vijaikumar]

-----Original Message-----
From: Henning Schild [mailto:henning...@siemens.com]
Sent: 03 March 2021 18:19
To: vijai kumar <vijaikumar....@gmail.com>
Cc: Kanagarajan, Vijaikumar <Vijaikumar_...@mentor.com>; isar-users <isar-...@googlegroups.com>; i...@radix10.net; Silvano Cirujano Cuesta <silvano.cir...@siemens.com>
Subject: Re: [RFC PATCH 1/2] dpkg-base: Handle custom source directory in do_apt_fetch

Can we please get this one stand-alone on the fast-path? Just ran into exactly the problem and now have to work around.

Sure Henning. Will take this out and send a v2 tonight.

[Henning Schild]

Sweet, this is what i just placed in a recipe

+## TODO hack, upstream will soon have a patch
+do_rename_to_s() {
+ debs=$( find ${WORKDIR} -type d -iname "${P}*" | head -1 )
+ rm -rf "${S}"
+ cp -a "$debs" "${S}"
+}
+addtask rename_to_s after do_apt_fetch

symlink will not work, since that is mounted into buildchroot

Henning

Am Wed, 3 Mar 2021 13:49:26 +0000
schrieb "Kanagarajan, Vijaikumar" <Vijaikumar_...@mentor.com>: