From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:aa7:d288:: with SMTP id w8mr2625942edq.241.1611048171761; Tue, 19 Jan 2021 01:22:51 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6402:1432:: with SMTP id c18ls2143297edx.0.gmail; Tue, 19 Jan 2021 01:22:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJxpz8VvM2at1Z5OvAaTdEkPSUc0tgAO6QXRV73sDm9/VlZrdIackw4xsOC9KuxK9BTBTdtW X-Received: by 2002:a50:a684:: with SMTP id e4mr2611147edc.148.1611048170779; Tue, 19 Jan 2021 01:22:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611048170; cv=none; d=google.com; s=arc-20160816; b=dxUM3qGdzncsydDxMQnWw0GcyCAfANyMOOoE2XPffRInBBc63Ga35p3Q+iq9qbi38X 0xxnrONBm7akPXyaFpnQUEKhX55YKcVKPKSWTej02PZBpm2dwPt/S7PewyUcld6+LPHL mbtxLFATHeh2/OWJVihPp/f9vofv14cYhnvrNwFV4HOP0SdJ32SNdSlPZDLZB+xplzuf qYR7K1gwv62Ya2Y7qqBhb8Vlq5Vrqld5zubl4f/9OzOoFsz8gzDvnXQEceRdfsTTS92Y TYstgkafBnxDxubB1Rk57i3Nvs0K9ae+BIaD4a3Ky3YiNopp6wegcl++Tx8VTBQ6JZiN oK6w== 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=zoELtnvS5C4uwY4/X+nS1oNmK/8J1B1KuFK33JUO+7g=; b=ZN5V8CjUFPlhK8kEzIKS89EFHQj6NeN506wMlOOBv/+3lwM1xR5sLpdRh/B4GM/lgX Ml+QVFHCW3ntufEtU0spEaI+kHJvtplnJEJKaMQrwYTvUiFOQabaZE5YqRlVrwU/gRJ1 qbyyuclnBrBEeZBDUqnQmU8WVG+CHh5LZijNaFRWDLKeX1zCrCFYR+3FytNZL3FLSbcR 6mbza4xBwFL6NqYsfVg8FvdZ/LK8DdMCICghGnUmvKy409kmof2Cu74kIifeeWzz1xxT C+3iiAdc3YvbmFDtOeJb3a5R+OdqFK1IQsw4oWDGdlnlv1AyqiYdDRDPEl5LwpH2RA7/ Dz3Q== 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 m5si363966edr.1.2021.01.19.01.22.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jan 2021 01:22:50 -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 mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 10J9Mnlc024991 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Jan 2021 10:22:49 +0100 Received: from md1za8fc.ad001.siemens.net ([139.22.120.228]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 10J9MnF5030936; Tue, 19 Jan 2021 10:22:49 +0100 Date: Tue, 19 Jan 2021 10:22:46 +0100 From: Henning Schild To: Silvano Cirujano Cuesta Cc: Claudius Heine , Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release Message-ID: <20210119102246.53791a9c@md1za8fc.ad001.siemens.net> In-Reply-To: <34c9ad2c-a330-0074-cfd1-bffa1afcbd02@siemens.com> References: <67e1fac9-5af5-29aa-de57-9a0de0cdd165@siemens.com> <79cdea42-8338-2e7f-33dd-f396db634a14@siemens.com> <20210119092531.2cc80db5@md1za8fc.ad001.siemens.net> <20210119093324.52410271@md1za8fc.ad001.siemens.net> <34c9ad2c-a330-0074-cfd1-bffa1afcbd02@siemens.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=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: hMVjjddA5Uk9 Am Tue, 19 Jan 2021 09:50:27 +0100 schrieb Silvano Cirujano Cuesta : > On 19/01/2021 09:33, Henning Schild wrote: > > Am Tue, 19 Jan 2021 09:25:31 +0100 > > schrieb "[ext] Henning Schild" : > > =20 > >> Am Mon, 18 Jan 2021 13:35:53 +0100 > >> schrieb Claudius Heine : > >> =20 > >>> Hi Silvano, > >>> > >>> 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. > >>>> > >>>> @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)? > >>>> > >>>> [1] > >>>> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= github.com%2Filbers%2Fisar%2Fcommit%2F13ce96e5bc84b60f2fa7ccfe93dde04546188= 4e6&data=3D04%7C01%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.sieme= ns.com%7Cfb6a5b02cdb74a01fe7708d8bc5745c5%7C38ae3bcd95794fd4addab42e1495d55= a%7C1%7C0%7C637466430297681379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DMLD8tTQoJ= prCpQsG%2BRL6oSg8jiR%2BUBUHG4J89VAEWDg%3D&reserved=3D0 > >>>> > >>>> =C2=A0 Silvano > >>>> > >>>> 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]. > >>>>> 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 > >>> Interesting, I didn't remember that `/etc/os-release` is a > >>> symlink, could that be something that has changed in more recent > >>> debian versions? > >>> > >>> If so then, of course that needs to be fixed. =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. > >> > >> My guess would be that we need to > >> - make it a copy instead of a symlink > >> - modify it =20 > > 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 =20 > No, nothing touching /etc/os-release off-band will block "base-files" > from restoring it. Creating another package touching /etc/os-release > will create a conflict that will be detected by dpkg. Either upstream > "base-files" is not there or we create a file diversion for > /etc/os-release. IMO we are creating a Debian Derivative and as > therefore I'd consider their re-/de-branding guidelines (see separate > thread). > > > > 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 =20 >=20 > Image post-processing is deemed to fail. >=20 > Sorry, I don't understand what you mean with "a package would become > subject to potential false sharing in the multiconfig case". A > package created on build-time can contain those image properties, > right? I might be missing something... No a package can not do the job, unfortunately. That is why we violate the rule that every modification should be part of a package. It is not because that file is potentially already owned by another package, that can always be solved with overwriting in a package hook. The package would need to have a unique name and version for every new output of "git describe" and for every image description. In multiconfig we build multiple images in one tree, sharing isar-apt. Henning > =C2=A0=C2=A0 Silvano >=20 > > > > 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. > >> > >> Henning > >> =20 > >>> regards, > >>> Claudius > >>> =20 >=20