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

[Henning Schild <henning.schild@siemens.com>]

Am Tue, 19 Jan 2021 09:25:31 +0100
schrieb "[ext] Henning Schild" <henning.schild@siemens.com>:

> Am Mon, 18 Jan 2021 13:35:53 +0100
> schrieb Claudius Heine <ch@denx.de>:
> 
> > Hi Silvano,
> > 
> > On 2021-01-18 12:35, Silvano Cirujano Cuesta wrote:  
> > > I might try to provide a fix, if we agree that the current
> > > implementation has an issue.
> > > 
> > > @Claudius: you wrote the original code [1]. Do you remember why
> > > you implemented it this way? Do you remember if you were aware of
> > > the issue I mentioned and you provided a mitigation for the issue
> > > that I see (assuming my analysis is right)?
> > > 
> > > [1]
> > > https://github.com/ilbers/isar/commit/13ce96e5bc84b60f2fa7ccfe93dde045461884e6
> > > 
> > >    Silvano
> > > 
> > > On 15/01/2021 15:26, [ext] Silvano Cirujano Cuesta wrote:    
> > >> Hi,
> > >>
> > >> 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?    
> > 
> > Interesting, I didn't remember that `/etc/os-release` is a symlink, 
> > could that be something that has changed in more recent debian
> > versions?
> > 
> > If so then, of course that needs to be fixed.  
> 
> the problem seems to be that it is a symlink, otherwise one would
> assume that changes in /etc/ are allowed and covered by the config
> file exception and will be subject to merging if an updated package
> comes around.
> 
> My guess would be that we need to
>  - make it a copy instead of a symlink
>  - modify it

Alternative would be to create /etc/os-release-isar as that modified
copy, and replace the symlink target /etc/os-release ->
/etc/os-release-isar

We can not have the modified file be part of any package, at least not
with its final content. The version control command has to happen on
every rootfs build and has to come "late", and a package would not have
that property. Plus a package would become subject to potential false
sharing in the multiconfig case ... The fields we change are mostly
image-properties, and not generic

Henning

> 
> In this case an update of the base-files package should leave it alone
> or ask for a merge. And i think that would be OK behaviour.
> 
> Henning
> 
> > regards,
> > Claudius
> >   
>