Re: image-postproc-extension.bbclass modifying /etc/os-release

[Baurzhan Ismagulov <ibr@radix50.net>]

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.


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