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

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

Am Tue, 19 Jan 2021 09:43:17 +0100
schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>:

> On 19/01/2021 09:25, Henning Schild wrote:
> > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Filbers%2Fisar%2Fcommit%2F13ce96e5bc84b60f2fa7ccfe93dde045461884e6&amp;data=04%7C01%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.siemens.com%7Cf108d28909264c483e3d08d8bc5646d1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637466426022621736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nXdIXZTWYDOaDvvJkYCD1q1rYY2dsKuKPj0nUexZz5U%3D&amp;reserved=0
> >>>
> >>>    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.  
> 
> No, that's wrong. The issue is not that it's a symlink, the issue is
> that it's a package-managed file that hasn't been declared as a
> configuration file.
> 
> I agree with you that files under /etc should be changeable, but...
> Debian found sort of a compromise between using the standard path
> /etc/os-release and not expecting it to be changed (symlink to
> /usr/lib and no configuration). You can like it or not, but that's
> what we have to live with...

We should not follow that symlink, but i would still hope that we are
allowed to recreate that file without the risk of that package
overwriting the file in /etc/ if it became a file and is modified.

Problem with the copy is that a major update would not be reflected.
Say your isar image starts off with debian9, a dist-upgrade might leave
you with 9 in there.

> > My guess would be that we need to
> >  - make it a copy instead of a symlink
> >  - modify it  
> As long as the file remains managed by "base-files", none of this
> should be done. Either we replace "base-files" or we create file
> diversions for those files. I wanted to focus this thread on
> confirming the issue, I've opened another thread to align on how to
> fix this issue. My proposal there is to contact the Debian
> Derivatives mailing list.

Dont know what a file diversion is, but also sounds like a hack that
would not cover the dist-upgrade correctly.

> >
> > 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.  
> 
> But that's not the case if updating upstream Debian "base-files", it
> silently replaces whatever we place there (file or symlink) with a
> symlink to /usr/lib/os-release.

Are you sure about that? That would have to be an "ln -sf" in a
postinst or something, maybe you can share a link to the code doing
that.

If there is code that overwrites a file in /etc without config file
protection, that would clearly be a reason to start talking to
upstream. Because it would be a violation of how config files work in
general.

Henning

>   Silvano
> 
> >
> > Henning
> >  
> >> regards,
> >> Claudius
> >>