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. 
>