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

[Claudius Heine <ch@denx.de>]

Hi Silvano,

On 2021-01-19 11:37, Silvano Cirujano Cuesta wrote:
> We can create a removal file diversion for /usr/lib/os-release (leaving /etc/os-release untouched, that way the Debian manpage for os-release still applies). This approach has following attributes:
> 
> - /usr/lib/os-release is not managed by any package and that way post-processing it is not an issue and dpkg won't break anything
> 
> - Debian os-release manpage still applies
> 
> If going for the other approach (create our own "base-files" package) we can do pretty much the same:
> 
> - the package doesn't provide /usr/lib/os-release, leaving it package-unmanaged
> 
> - image post-processing to create the file becomes a requirement
I looked at the manpage of os-release and it does not state that 
`/etc/os-release` can or should not be a file:

```
        The file /etc/os-release takes precedence over 
/usr/lib/os-release. Applications should check for the former, and 
exclusively use its data if it exists, and only fall back to 
/usr/lib/os-release if
        it is missing. Applications should not read data from both files 
at the same time.  /usr/lib/os-release is the recommended place to store 
OS release information as part of vendor trees.
        /etc/os-release should be a relative symlink to 
/usr/lib/os-release, to provide compatibility with applications only 
looking at /etc/. A relative symlink instead of an absolute symlink is 
necessary
        to avoid breaking the link in a chroot or initrd environment 
such as dracut.

        os-release contains data that is defined by the operating system 
vendor and should generally not be changed by the administrator.

        As this file only encodes names and identifiers it should not be 
localized.

        The /etc/os-release and /usr/lib/os-release files might be 
symlinks to other files, but it is important that the file is available 
from earliest boot on, and hence must be located on the root file
        system.
```

So why not make sure `/etc/os-release` is a file and do this:

     dpkg-divert --add --local --no-rename /etc/os-release

in the post processing step? Shouldn't this prevent any future 
base-files update from preventing to overwrite the `/etc/os-release`?

The only issue I would see if someone performs a distribution upgrade 
and now the `/etc/os-release` no longer contains the correct version, 
but other than an apt.conf hook that updates `/etc/os-release` based on 
new information from `/usr/lib/os-release` after an upgrade, I don't see 
a way to do this automatically.

I would rather divert '/etc/os-release' in a postprocessing script than 
`/usr/lib/os-release` because, I see the post-processing more of a local 
configuration.

For multiple reasons we cannot used a package to write the version 
information, so that is out of the picture anyway.

The only other way would be to create a new file just for the image or 
build version, but that would break compatibility now.

regards,
Claudius