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

[Baurzhan Ismagulov <ibr@radix50.net>]

Hello Silvano,

On Fri, Jan 15, 2021 at 03:26:14PM +0100, Silvano Cirujano Cuesta wrote:
> 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?

Thanks for raising this topic. I'd like to address some of the issues.

* I see identification as a downstream issue. However, it would be nice to
  provide something by default. Thus we touch os-release.

* Regarding an Isar-specific identification file: This is advised against in
  http://0pointer.de/blog/projects/os-release.html.

* Breaking /etc/os-release -> ../usr/lib/os-release is a bug. We should modify
  /usr/lib/os-release, in whatever way. We should not break the symlink. I
  agree we should fix this.

* Isar was conceived as a rootfs builder that should be able to work without
  creating a derivative (remember SLIND). If a downstream feels like it, they
  may create a derivative.

* For a given rootfs, the identification information is intrinsically static.
  Thus, the best would be to provide it in a static way, e.g. by patching (the
  current approach) or providing base-files (I see this as a downstream issue).

* os-release contains static information and doesn't have user-modifiable
  contents. Thus, I agree with Debian that this is not a config file.

* Upgrading base-files would overwrite os-release. From Isar point of view, I'm
  fine with that; after all, it isn't the original image, it's image + upgrade
  -- the identification should be changed as well.

* If a downstream wants to preserve the identification through package
  upgrades, they should provide their own base-files. Maybe we could make it
  easier for them in stock Isar.

* Since the information is static, dynamic approaches (config files, postinst,
  alternatives, diversions) are not necessary. They are more complex than they
  seem at the first glance (package upgrade order, package removal order,
  downgrades, failed upgrades, idempotency, etc.).

To summarize, I suggest fixing /etc/os-release -> ../usr/lib/os-release
symlink breakage.

If there is an itch for the upgrade problem, I'd be open for the discussion
on providing base-files with Isar.

With kind regards,
Baurzhan.