From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 X-Received: by 2002:a05:6512:1088:: with SMTP id j8mr1418068lfg.475.1611047690852; Tue, 19 Jan 2021 01:14:50 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:810b:: with SMTP id d11ls3170977ljg.11.gmail; Tue, 19 Jan 2021 01:14:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJze5cOmX9IdOzx6axPcQfTuGp/vz4hSmYQgBtpUgkmx6OZVNF5guAKCLE9VVeGGMmMh/uWX X-Received: by 2002:a2e:6a12:: with SMTP id f18mr1447333ljc.174.1611047689922; Tue, 19 Jan 2021 01:14:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611047689; cv=none; d=google.com; s=arc-20160816; b=sxIwtmdcV/ZjVzELH1HZ2i5iei6/cJLDOa2YUBvRI9NOCkzhfznyECtXqRtjgFosit nHi5Irtnu4LZhmImzI9DPNnCbOfePUeVEaJ89k1oNiiFM+i2DDW4gIA7LJhgnIyVE81C MQ3gyNVBUQ8ZBves7upaB/l76zezfFCO22hLxcZbLGDX0IJreeWSEp3TmYxROQvFrqgo w508Gz1mg3vG3YcxMPZpG40DSf1whMocRur/fRLODevabX+882ByPHL41DqVeA3f4nW7 nnwAxVZpXjapE1ofCutvy4zzta/D5gw7oz1b61vGe1LsLI8oVpaeL0wvhD6SgNnUinsX kqpw== 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=GSCS6ee66G+a3HRPqmuekssShZVPeBkI2N6YEwd7VOk=; b=hAsHmUyFOseD6AIi4wdhEWFhhyObcvvswtd5oDWZKXerjY9c7pJ2+b57/kDo5sqfCB 7NB2PTYlEVU8JQ0EWmAXol66aVQk542M1LUFBiOhMsovxCjVj59TviDCv17yyvWrZjgX iOr/GdOuldXAuPMEoqOd0k8xdxWvA8W431Mjdg5hhx5ubHon4QJ9SvDjf+vd3DkMrwhY 6P5lFyLWjc580OVf/K43Q/WF7bfL0Wn5D2BtjqeZN6Mv0BRw49vEcu4mfdK7Qi8/nVLY UB/JK+JTAFN0Y1FKl8YJNh/hhB/CM5cdJmwkm0f+JUpQKL8a2x8SNWSqOBWFb5s9uGWk agnQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id f21si1059220lfe.9.2021.01.19.01.14.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jan 2021 01:14:48 -0800 (PST) Received-SPF: neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 10J9ElwR002724 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Jan 2021 10:14:48 +0100 Received: from md1za8fc.ad001.siemens.net ([139.22.120.228]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 10J9El9w003643; Tue, 19 Jan 2021 10:14:47 +0100 Date: Tue, 19 Jan 2021 10:14:44 +0100 From: Henning Schild To: Silvano Cirujano Cuesta Cc: Claudius Heine , Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release Message-ID: <20210119101444.6e5dc270@md1za8fc.ad001.siemens.net> In-Reply-To: <20210119100825.7b56d4fd@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> <1ffb481e-f64e-01d8-efe7-5e4dbc39d8cb@siemens.com> <20210119100825.7b56d4fd@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: P8HbyaQlqKqu Am Tue, 19 Jan 2021 10:08:25 +0100 schrieb Henning Schild : > Am Tue, 19 Jan 2021 09:43:17 +0100 > schrieb Silvano Cirujano Cuesta : >=20 > > On 19/01/2021 09:25, Henning Schild wrote: =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%2= Fgithub.com%2Filbers%2Fisar%2Fcommit%2F13ce96e5bc84b60f2fa7ccfe93dde0454618= 84e6&data=3D04%7C01%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.siem= ens.com%7Cf108d28909264c483e3d08d8bc5646d1%7C38ae3bcd95794fd4addab42e1495d5= 5a%7C1%7C0%7C637466426022621736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA= iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DnXdIXZTW= YDOaDvvJkYCD1q1rYY2dsKuKPj0nUexZz5U%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. =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... =20 >=20 > 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. >=20 > 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. >=20 > > > 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. =20 >=20 > Dont know what a file diversion is, but also sounds like a hack that > would not cover the dist-upgrade correctly. >=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 > >=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. =20 >=20 > 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. >=20 > 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. Indeed, it does overwrite a modified copy ignoring config file protection. rm /etc/os-release=20 cp /usr/lib/os-release /etc/os-release vim /etc/os-release apt-get install base-files --reinstall ls -al /etc/os-release It is also replaced when it is a symlink to another location. Henning > Henning >=20 > > =C2=A0 Silvano > > =20 > > > > > > Henning > > > =20 > > >> regards, > > >> Claudius > > >> =20 >=20