From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6917993065941565440 Date: Wed, 10 Feb 2021 21:54:39 -0800 (PST) From: "vijaikumar....@gmail.com" To: isar-users Message-Id: <0fa156df-7943-47ce-86a6-cf02fe5d4d0dn@googlegroups.com> In-Reply-To: <20210210092248.GX20742@yssyq.m.ilbers.de> References: <12759268-1ad7-168a-dde9-4f2658567af1@siemens.com> <402794f7-74a3-ab50-972e-7682d5388ff2@denx.de> <0beb8d2d-5141-647c-a831-8693276c957a@siemens.com> <333bd498-2e79-bb2d-ef84-3f6ab68a68b9@denx.de> <6f4b945f-7763-49ee-a8c5-2e02d450a2e0n@googlegroups.com> <6473666c-a754-0512-0000-a072f4530d3f@siemens.com> <3bbb9c63-6f3c-d0c9-416e-31edb430642f@siemens.com> <20210210092248.GX20742@yssyq.m.ilbers.de> Subject: Re: image-postproc-extension.bbclass modifying /etc/os-release MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_232_2083385022.1613022879163" X-TUID: OsQxbM4sJy5b ------=_Part_232_2083385022.1613022879163 Content-Type: multipart/alternative; boundary="----=_Part_233_424514239.1613022879163" ------=_Part_233_424514239.1613022879163 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Baurzhan, On Wednesday, February 10, 2021 at 2:52:52 PM UTC+5:30 i...@radix50.net wrote: > On Sun, Feb 07, 2021 at 12:31:23AM -0800, vijaikumar....@gmail.com wrote: > > > If we need to provide "something" that keeps modifying the > /etc/os-release > > > for backwards compatibility, do we want to keep the current "broken" > > > implementation? > > > > I would not suggest keeping it as it is. We know it is broken. Better to > > fix it. > > I suggest to patch /usr/lib/os-release as the first step to preserve the > /etc/os-release symlink (we could provide a patch), then see whether we > want to > optionally provide base-files in Isar. > > > > > If we want to "fix" that implementation, then we can do it in a way > that > > > not only provides that backwards compatibility, but also to provides a > > > useful feature. The default would be not touching /etc/os-release and > one > > > recipe could provide (when requested with a flag) a package for > "managing" > > > /etc/os-release (assuming it can be somehow accomplished with > multiconfigs, > > > or be a mutually exclusive feature). > > > > > > > As Claudius previously mentioned, this might break caching. If the > > information is purely build-system related, should we try to put it in a > > package? Does this file need updates in the future? Well, from the > current > > standpoint, I don't see it needing updates. The data is only applicable > > when we build using ISAR. If hypothetically, we decided to recreate the > > distro with the cached apt-repo generated with ISAR using some other > tool, > > this info is not relevant. > > Under "caching" I understand base-apt. Providing base-files in Isar > shouldn't > break base-apt. Isar-generated base-files would land in isar-apt. Updating > that > file again and again with every new build is a normal project lifecycle. > > > > That said, we need to understand from the community, what are the > real-life > > scenarios they are using this ISAR information in /etc/os-release for? I > am > > not personally using that info. If it is being used somewhere, we need > to > > know why? So that we know how costly it is to break backward > compatibility. > > Huge or none at all? > > I only use it visually when I log into the target. > > > On Tue, Feb 09, 2021 at 11:32:30AM +0530, vijai kumar wrote: > > I do > > agree that the current way of changing the content of /etc/os-release > > is an error, since now we know that it belongs to base-files and its > > update makes that information disappear. > > While I agree that patching os-release is not optimal, overwriting on > upgrade > being a bug or not depends IMHO on whether a downstream declares itself a > distro or not. If they don't, let Debian overwrite it -- it isn't an > Isar-generated image anymore. If they do, they should provide their own > base-files. > Since ISAR is providing that information by default, and people use it based on upstream trust, we should probably have that information in a way that it is usable even after an upgrade. Or not provide it at all. I am more inclined to base-files approach here since we know that /etc/os-release is maintained by it. Since providing another file is not the recommended way, as per Debian, we should probably provide the isar information in /etc/os-release through custom base-files in upstream isar for reference. Do you feel it is a strong enough reason to have custom base-files in ISAR? If so, I could try and send a patch for RFC sometime later. Thanks, Vijai Kumar K > > > > Agreed. /etc/os-release is supposed to be extendable. And looks like > > there is no hard and fast rule which describes what is "OS > > information". It could be accomplished by modifying base-files. I > > would recommend ISAR support something similar to it instead of > > bringing in a new package to handle /etc/os-release, which by the way > > is redundant. > > If this is about providing base-files in Isar, I'm open to the discussion. > A > modified package would be cleaner than patching the rootfs. That said, my > itch > isn't currently that strong to provide a patch :) . > > > With kind regards, > Baurzhan. > ------=_Part_233_424514239.1613022879163 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Baurzhan,

On Wednesday, February 10, 2021 at 2:52:52 PM UTC+5:30 i...@rad= ix50.net wrote:
vijaikumar....@gmail.com wrote:
> > If we need to provide "something" that keeps modifying the /e= tc/os-release=20
> > for backwards compatibility, do we want to keep the current "= broken"=20
> > implementation?=20
>=20
> I would not suggest keeping it as it is. We know it is broken. Bet= ter to=20
> fix it.

I suggest to patch /usr/lib/os-release as the first step to preserve th= e
/etc/os-release symlink (we could provide a patch), then see whether we= want to
optionally provide base-files in Isar.


> > If we want to "fix" that implementation, then we can do it in= a way that=20
> > not only provides that backwards compatibility, but also to p= rovides a=20
> > useful feature. The default would be not touching /etc/os-rel= ease and one=20
> > recipe could provide (when requested with a flag) a package f= or "managing"=20
> > /etc/os-release (assuming it can be somehow accomplished with= multiconfigs,=20
> > or be a mutually exclusive feature).=20
> >
>=20
> As Claudius previously mentioned, this might break caching. If the= =20
> information is purely build-system related, should we try to put i= t in a=20
> package? Does this file need updates in the future? Well, from the= current=20
> standpoint, I don't see it needing updates. The data is only appli= cable=20
> when we build using ISAR. If hypothetically, we decided to recreat= e the=20
> distro with the cached apt-repo generated with ISAR using some oth= er tool,=20
> this info is not relevant.

Under "caching" I understand base-apt. Providing base-files in Isar sho= uldn't
break base-apt. Isar-generated base-files would land in isar-apt. Updat= ing that
file again and again with every new build is a normal project lifecycle= .


> That said, we need to understand from the community, what are the = real-life=20
> scenarios they are using this ISAR information in /etc/os-release = for? I am=20
> not personally using that info. If it is being used somewhere, we = need to=20
> know why? So that we know how costly it is to break backward compa= tibility.=20
> Huge or none at all?

I only use it visually when I log into the target.


On Tue, Feb 09, 2021 at 11:32:30AM +0530, vijai kumar wrote:
> I do
> agree that the current way of changing the content of /etc/os-rele= ase
> is an error, since now we know that it belongs to base-files and i= ts
> update makes that information disappear.

While I agree that patching os-release is not optimal, overwriting on u= pgrade
being a bug or not depends IMHO on whether a downstream declares itself= a
distro or not. If they don't, let Debian overwrite it -- it isn't an
Isar-generated image anymore. If they do, they should provide their own
base-files.

Since ISAR is providing that informati= on by default, and people use it based
on upstream trust, we shou= ld probably have that information in a way that it
is usable even= after an upgrade. Or not provide it at all. I am more inclined to 
base-files approach here since we know that /etc/os-release is main= tained by it.
Since providing another file is not the recommended= way, as per Debian, we
should probably provide the isar informat= ion in /etc/os-release through custom
base-files in upstream isar= for reference.

Do you feel it is a strong enough = reason to have custom base-files in ISAR?

If so, I= could try and send a patch for RFC sometime later.

Thanks,
Vijai Kumar K
 


> Agreed. /etc/os-release is supposed to be extendable. And looks li= ke
> there is no hard and fast rule which describes what is "OS
> information". It could be accomplished by modifying base-files. I
> would recommend ISAR support something similar to it instead of
> bringing in a new package to handle /etc/os-release, which by the = way
> is redundant.

If this is about providing base-files in Isar, I'm open to the discussi= on. A
modified package would be cleaner than patching the rootfs. That said, = my itch
isn't currently that strong to provide a patch :) .


With kind regards,
Baurzhan.
------=_Part_233_424514239.1613022879163-- ------=_Part_232_2083385022.1613022879163--