From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:a1c:25c2:: with SMTP id l185mr2910250wml.62.1611045209851; Tue, 19 Jan 2021 00:33:29 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:385:: with SMTP id 127ls7617974wmd.0.canary-gmail; Tue, 19 Jan 2021 00:33:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJwgloGQDl7xYLkMeXHPPWgidC/MHYinrPrKZ2KPyqgyyd50J9Wc7zyvVB+D9c0seexlbNl1 X-Received: by 2002:a1c:96d7:: with SMTP id y206mr2972098wmd.9.1611045209027; Tue, 19 Jan 2021 00:33:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611045209; cv=none; d=google.com; s=arc-20160816; b=OPrSiBfKc1zSQD9QTisq1K1279/EhAgWOhV/NHuGA33jH0CrfgXmd526jS/s617GOJ dzVn63lzEWomdmpXH41LGjIlTTIheMF9l960yCKKaqa663M+BsbaSz3RHuRMIDHovIoo yH0difkddmklHzbPcPceuJzRh5IgOhA5G0zrdnHJaNnJA1BJG62/3PsmK09V/2rgRW8l 7ZMIsENpOmWKaJaewXbEsJlPmZ/e0O+UQ6P8IqdQATWPK+MIXrOIBW03kFVM7+zpLVkf 9OtgcC+kJiX86M3lrpGLtmtb/nvdsDmdzxwSDQ+jTdUyKcluMKVeHU2vWVfhftulp82c npog== 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=Tb/qJ4YbJ7rMFxu3jCl3n4C1/C9+08IyaP0GeqQImtw=; b=PQx9tkf9U8II7rIIa2l8AWHWwmCoiXty1vJoCBi0N+AoZoyKL2jQ4oQI4OODg2B068 wwlHb+28gJLxdZPePTywcGP8Xbm2jXvyby0y5Jf5BZDrNNFRN2VWnya+luls+t4zNVeM SbqjDXVqlwfOaiSb6LnBx1d6XP4qeWyCnjYPGU94xMRPNhQ2EqzAajs36oJfDdIp7brC dNp3e/DN16EX6FE2I/5eQfsRjfY4OfYMwFSHY3QJXNF1dNKZQ4eTV1EnWMmZTPN4HSyv LSLmJuf/fBzx2yMV+Vn7C8+duP7rNnEfdmjITPoSmab3kDKzgDNgDbYesosvqm74xKUd 7QHg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id i4si148221wml.0.2021.01.19.00.33.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jan 2021 00:33:28 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 10J8XRVp026976 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Jan 2021 09:33:27 +0100 Received: from md1za8fc.ad001.siemens.net ([139.22.120.228]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 10J8XQtZ022707; Tue, 19 Jan 2021 09:33:26 +0100 Date: Tue, 19 Jan 2021 09:33:24 +0100 From: Henning Schild To: Claudius Heine Cc: Silvano Cirujano Cuesta , isar-users@googlegroups.com Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release Message-ID: <20210119093324.52410271@md1za8fc.ad001.siemens.net> In-Reply-To: <20210119092531.2cc80db5@md1za8fc.ad001.siemens.net> References: <67e1fac9-5af5-29aa-de57-9a0de0cdd165@siemens.com> <79cdea42-8338-2e7f-33dd-f396db634a14@siemens.com> <20210119092531.2cc80db5@md1za8fc.ad001.siemens.net> 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: 07soxUjIhVcQ Am Tue, 19 Jan 2021 09:25:31 +0100 schrieb "[ext] Henning Schild" : > Am Mon, 18 Jan 2021 13:35:53 +0100 > schrieb Claudius Heine : >=20 > > Hi Silvano, > >=20 > > On 2021-01-18 12:35, Silvano Cirujano Cuesta wrote: =20 > > > I might try to provide a fix, if we agree that the current > > > implementation has an issue. > > >=20 > > > @Claudius: you wrote the original code [1]. Do you remember why > > > you implemented it this way? Do you remember if you were aware of > > > the issue I mentioned and you provided a mitigation for the issue > > > that I see (assuming my analysis is right)? > > >=20 > > > [1] > > > https://github.com/ilbers/isar/commit/13ce96e5bc84b60f2fa7ccfe93dde04= 5461884e6 > > >=20 > > > =C2=A0 Silvano > > >=20 > > > On 15/01/2021 15:26, [ext] Silvano Cirujano Cuesta wrote: =20 > > >> Hi, > > >> > > >> I've noticed that '/etc/os-release' is being changed on the image > > >> in meta/classes/image-postproc-extension.bbclass [1].=C2=A0 What BTW > > >> ends up changing '/usr/lib/os-release', since it's only a > > >> symlink. But both '/etc/os-release' and '/usr/lib/os-release' > > >> are owned by 'base-files'... > > >> > > >> An upgrade of 'base-files' would be replacing (silently, since is > > >> not marked as a configuration file) '/usr/lib/os-release' with > > >> the version of the upstream 'base-files' package and possibly > > >> breaking any tools in the system relying on certain values in > > >> that file. > > >> > > >> Is there a reason that I'm missing for doing so instead of the > > >> Debian-way (file diversion with dpkg-divert)? Or any hack that > > >> I've overseen that avoids the mentioned breakage? =20 > >=20 > > Interesting, I didn't remember that `/etc/os-release` is a symlink,=20 > > could that be something that has changed in more recent debian > > versions? > >=20 > > If so then, of course that needs to be fixed. =20 >=20 > the problem seems to be that it is a symlink, otherwise one would > assume that changes in /etc/ are allowed and covered by the config > file exception and will be subject to merging if an updated package > comes around. >=20 > My guess would be that we need to > - make it a copy instead of a symlink > - modify it Alternative would be to create /etc/os-release-isar as that modified copy, and replace the symlink target /etc/os-release -> /etc/os-release-isar We can not have the modified file be part of any package, at least not with its final content. The version control command has to happen on every rootfs build and has to come "late", and a package would not have that property. Plus a package would become subject to potential false sharing in the multiconfig case ... The fields we change are mostly image-properties, and not generic Henning >=20 > In this case an update of the base-files package should leave it alone > or ask for a merge. And i think that would be OK behaviour. >=20 > Henning >=20 > > regards, > > Claudius > > =20 >=20