[devel-distro] branding

[Anton Farygin]

On 02.09.2021 21:20, Dmitry V. Levin wrote:
> On Thu, Sep 02, 2021 at 09:17:11PM +0300, Anton Farygin wrote:
>> On 02.09.2021 21:15, Dmitry V. Levin wrote:
>>> On Thu, Sep 02, 2021 at 09:13:18PM +0300, Anton Farygin wrote:
>>>> On 02.09.2021 20:09, Dmitry V. Levin wrote:
>>>>> On Thu, Sep 02, 2021 at 07:46:11PM +0300, Leonid Krivoshein wrote:
>>>>>> 02.09.2021 11:26, Sergey V Turchin пишет:
>>>>>>> 01.09.2021 20:08, Leonid Krivoshein пишет:
>>>>>>>> 01.09.2021 18:01, Sergey V Turchin пишет:
>>>>>>>>> 01.09.2021 15:33, Leonid Krivoshein пишет:
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>> Но не из самого /etc/os-release, а того, что лежит в /usr/share
>>>>>>>>> Не /usr/share, а из /usr/lib/os-release.
>>>>>>>>> https://www.freedesktop.org/software/systemd/man/os-release.html
>>>>>>>> Не, это о другом. Я имел ввиду наше внутреннее:
>>>>>>>> /usr/share/branding-data-current/release/os-release
>>>>>>> Так, разговор и о том, чтоб без велосипедов.
>>>>>>>
>>>>>> Стандарт предписывает "клиентам" брать данные из /etc/os-release и, если
>>>>>> его нет, то из /usr/lib/os-release, т.е. это одна и та же сущность,
>>>>>> второй может не быть, если есть первая. Здесь "клиент" -- это тот, кто
>>>>>> хочет сориентироваться в текущем окружении, типа ansible.
>>>>>>
>>>>>> То, что у нас лежит в /usr/share -- это не велосипед, а оригинальный
>>>>>> неизменяемый файл, поставлявшийся с пакетом. Из него в /etc/os-release
>>>>>> сейчас копируется информация в пост-установочном скрипте, сам
>>>>>> /etc/os-release сейчас является файлом конфигурации, и он не меняется с
>>>>>> обновлением пакета брэндинга.
>>>>>>
>>>>>> Предлагается в rpm сделать файл-триггер, который будет генерировать
>>>>>> содержимое /etc/os-release, полностью соответствующее стандарту. В новом
>>>>>> варианте здесь будут данные, соответствующие текущей ситуации, а не той,
>>>>>> что была. Но обсуждается вариант сохранения информации, соответствующие
>>>>>> исходному состоянию системы. Рассмотрены два варианта:
>>>>>>
>>>>>> - Сохранять все поля, добавляя к ним альтовый префикс, что допускается
>>>>>> стандартом.
>>>>>> - Сохранять только поле BUILD_ID, а в его отсутствии брать значение из
>>>>>> VERSION_ID (в /etc/os-release).
>>>>>>
>>>>>> Файл-триггер будет брать СОХРАНЯЕМЫЕ значение из /etc/os-release,
>>>>>> остальные поля перезаписывать из
>>>>>> /usr/share/branding-data-current/release/os-release. При даунгрейде
>>>>>> пакета брэндинга схема будет в точности такой же.
>>>>> Наверное, эта деталь не очень важна, но я полагал, что файлтриггер будет
>>>>> смотреть не напрямую в
>>>>> /usr/share/branding-data-current/release/os-release, а в
>>>>> /usr/lib/os-release, который, в свою очередь, будет относительной ссылкой
>>>>> на тот же /usr/share/branding-data-current/release/os-release.
>>>>>
>>>> Во время работы файлтриггера в этом месте данные будут уже обновлены.
>>>>
>>>> А вот в /etc/os-release они всё ещё остануться старые.
>>> Беспокоит окно между моментом обновления /usr/lib/os-release и моментом,
>>> когда отработает файлтриггер, обновляющий /etc/os-release?
>> нет,  /usr/lib/os-release обновляется из пакета. во время работы
>> файлтриггера пакет будет установлен уже новый, в котором эти данные
>> могут быть изменены.
>>
>> Надо брать данные для os-release из старого пакета, до обновления.
> Разве в /etc/os-release уже не находятся старые данные, которые как раз
> и надо обновить из /usr/lib/os-release после обновления последнего?

Мы говорим о разных файлтриггерах. Если нам нужно первый раз получить 
BUILD_ID, то в /usr/lib/os-release он будет уже новый, а в 
/etc/os-release - старый (который нам как раз и нужен)

Если мы говорим про обновление остальных данных, то да, файлтриггер 
должен конечно должен брать их уже из /usr/lib/os-release