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

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

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

> On 19/01/2021 09:33, Henning Schild wrote:
> > 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://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%7Cfb6a5b02cdb74a01fe7708d8bc5745c5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637466430297681379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=MLD8tTQoJprCpQsG%2BRL6oSg8jiR%2BUBUHG4J89VAEWDg%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.
> >>
> >> 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  
> No, nothing touching /etc/os-release off-band will block "base-files"
> from restoring it. Creating another package touching /etc/os-release
> will create a conflict that will be detected by dpkg. Either upstream
> "base-files" is not there or we create a file diversion for
> /etc/os-release. IMO we are creating a Debian Derivative and as
> therefore I'd consider their re-/de-branding guidelines (see separate
> thread).
> >
> > 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  
> 
> Image post-processing is deemed to fail.
> 
> Sorry, I don't understand what you mean with "a package would become
> subject to potential false sharing in the multiconfig case". A
> package created on build-time can contain those image properties,
> right? I might be missing something...

No a package can not do the job, unfortunately. That is why we violate
the rule that every modification should be part of a package. It is not
because that file is potentially already owned by another package, that
can always be solved with overwriting in a package hook.

The package would need to have a unique name and version for every new
output of "git describe" and for every image description. In
multiconfig we build multiple images in one tree, sharing isar-apt.

Henning

>    Silvano
> 
> >
> > 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
> >>>     
>