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.