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

[Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>]

On 19/01/2021 10:22, Henning Schild wrote:
> 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%7Csilvano.cirujano-cuesta%40siemens.com%7C7170c79e6ec14d6df1ac08d8bc5bcaf8%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637466449720721035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ejDae1qkGm4bNOnsk1oRZeGGkJLs7tXVmhHx%2B4pnv2Q%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.

What do you mean with "package hook"? A package "postinst" script?

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

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

  Silvano

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

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