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

[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%7Csilvano.cirujano-cuesta%40siemens.com%7Ce6139ab1b7d14094332e08d8bc53cb38%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637466415364594960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3jkRDpGDsHDLUs315h%2Fyx40841JT4RpHa%2BvqQ7fD%2FXk%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...

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

  Silvano

>
> Henning
>
>> regards,
>> Claudius
>>
-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux