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

[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%7Csilvano.cirujano-cuesta%40siemens.com%7Cc75c1ca076a0460e8a2a08d8bc54e4dd%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637466420092677953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=c3d3xPuWoZC616jMfcDeqo9g1zolQIYgHsN%2FdKc1RC8%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...

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

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux