From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:adf:f60b:: with SMTP id t11mr3313009wrp.401.1611047310371; Tue, 19 Jan 2021 01:08:30 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:385:: with SMTP id 127ls7684796wmd.0.canary-gmail; Tue, 19 Jan 2021 01:08:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJwAyqvckOZcZR/HmeB0TqS8TXVjyUVi8HhFD3qOgQloAqF7W9TdkXGZNZI8oNaUlSQ1Rs/V X-Received: by 2002:a1c:9d8b:: with SMTP id g133mr3074963wme.44.1611047309416; Tue, 19 Jan 2021 01:08:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611047309; cv=none; d=google.com; s=arc-20160816; b=okukG8LVnhGX1FzgQFn67mq+iPA9ILEFCrhFDU17QsZt75orvlfWhpOokK2V9TfpDi VLjvynDJhmG/P48J4hxvlo8PLMCDNYYFnHhmojr1M38HRhDX8YM0ByjfFDU/jSgXd6ou X3uyBWv4DJ1j+PJwmOMD93S1uDTRTZTj3fhcxRDe/QKXU0LGnHTcZTQoDXRtKkYkTpoN trPuwDziRFQ8YS7qBXPcw6WwlLDHuVYUBcCpERv6A8JiI4PrLVpbnQ5CUudyyhMgMWIk P4zoGuMHOR+hSpiOQvUDtw04nLrT1rQPKWzIM1LCxpdR84chK9eSJ/G5nspKaBxaDXQ9 Hx6g== 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=tnKTTg6/MCUOAw+dC0B1Q+wVfZed3qLsj/+VASp/NUA=; b=zDELFeXSgqJStk2OKjbzslRUFTBvi62ayXztjPJp65s1QQwqNv7SupTXlDk87vn6vx GFWHCHMPH7pvy25M64YCRFkfBEYorRyhe9sGKpMdo2kSyks1pOcRAC30bcRifGY6nGCx pNzk3DbAMLfGuXl6w58s0aegM1TLvfZYybqA8a7OmtYYANbmsTR+HLBLTrM6XlQEQ3kv NeYxW4P32mz9TaR5Re3i1uJimdNe2Ac7B/hgQz1wmydEjBx4TUf7Yff/FzC/8odsSOq9 F8ZhT/QsYWsnQCmIj9u2+SYT8/ZKkrOWmaTEkdMfSct4c0/oTZ8W+hyZrWsmxjOkwFqL aMkg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 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 david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id y1si954913wrl.4.2021.01.19.01.08.29 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jan 2021 01:08:29 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 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 david.siemens.de (8.15.2/8.15.2) with ESMTPS id 10J98SKL008563 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Jan 2021 10:08:28 +0100 Received: from md1za8fc.ad001.siemens.net ([139.22.120.228]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 10J98SPT015109; Tue, 19 Jan 2021 10:08:28 +0100 Date: Tue, 19 Jan 2021 10:08:25 +0100 From: Henning Schild To: Silvano Cirujano Cuesta Cc: Claudius Heine , Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release Message-ID: <20210119100825.7b56d4fd@md1za8fc.ad001.siemens.net> In-Reply-To: <1ffb481e-f64e-01d8-efe7-5e4dbc39d8cb@siemens.com> References: <67e1fac9-5af5-29aa-de57-9a0de0cdd165@siemens.com> <79cdea42-8338-2e7f-33dd-f396db634a14@siemens.com> <20210119092531.2cc80db5@md1za8fc.ad001.siemens.net> <1ffb481e-f64e-01d8-efe7-5e4dbc39d8cb@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: JOAgY1H9aDeI Am Tue, 19 Jan 2021 09:43:17 +0100 schrieb Silvano Cirujano Cuesta : > On 19/01/2021 09:25, Henning Schild wrote: > > 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%2Fg= ithub.com%2Filbers%2Fisar%2Fcommit%2F13ce96e5bc84b60f2fa7ccfe93dde045461884= e6&data=3D04%7C01%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.siemen= s.com%7Cf108d28909264c483e3d08d8bc5646d1%7C38ae3bcd95794fd4addab42e1495d55a= %7C1%7C0%7C637466426022621736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL= CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DnXdIXZTWYD= OaDvvJkYCD1q1rYY2dsKuKPj0nUexZz5U%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].=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 > >> 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. =20 >=20 > No, that's wrong. The issue is not that it's a symlink, the issue is > that it's a package-managed file that hasn't been declared as a > configuration file. >=20 > I agree with you that files under /etc should be changeable, but... > Debian found sort of a compromise between using the standard path > /etc/os-release and not expecting it to be changed (symlink to > /usr/lib and no configuration). You can like it or not, but that's > what we have to live with... We should not follow that symlink, but i would still hope that we are allowed to recreate that file without the risk of that package overwriting the file in /etc/ if it became a file and is modified. Problem with the copy is that a major update would not be reflected. Say your isar image starts off with debian9, a dist-upgrade might leave you with 9 in there. > > My guess would be that we need to > > - make it a copy instead of a symlink > > - modify it =20 > As long as the file remains managed by "base-files", none of this > should be done. Either we replace "base-files" or we create file > diversions for those files. I wanted to focus this thread on > confirming the issue, I've opened another thread to align on how to > fix this issue. My proposal there is to contact the Debian > Derivatives mailing list. Dont know what a file diversion is, but also sounds like a hack that would not cover the dist-upgrade correctly. > > > > 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 >=20 > But that's not the case if updating upstream Debian "base-files", it > silently replaces whatever we place there (file or symlink) with a > symlink to /usr/lib/os-release. Are you sure about that? That would have to be an "ln -sf" in a postinst or something, maybe you can share a link to the code doing that. If there is code that overwrites a file in /etc without config file protection, that would clearly be a reason to start talking to upstream. Because it would be a violation of how config files work in general. Henning > =C2=A0 Silvano >=20 > > > > Henning > > =20 > >> regards, > >> Claudius > >> =20