[devel-distro] branding

[Anton Farygin]

On 02.09.2021 21:33, Dmitry V. Levin wrote:
> On Thu, Sep 02, 2021 at 09:23:26PM +0300, Anton Farygin wrote:
>> 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:
> [...]
>>>>>>>> Стандарт предписывает "клиентам" брать данные из /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
> Мне кажется, что это один и тот же файлтриггер, который оставляет BUILD_ID
> в /etc/os-release старым (а если там нет BUILD_ID, то клонирует VERSION_ID
> в BUILD_ID), а всё остальное копирует из /usr/lib/os-release.
>
> Остаётся вопрос, что делать с теми полями, которые есть в /etc/os-release,
> но нет в /usr/lib/os-release - оставлять или удалять?
>


Я предлагаю оставлять, тем самым дав возможность тем, кто выпускает 
дистрибутивы дополнить /etc/os-release какими-то нужными им данными, не 
предполагающими обновления.