From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1d09cf45-dacc-4c58-a8d2-ff62787e9c79@basealt.ru> Date: Thu, 2 Sep 2021 21:35:44 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0.3 Content-Language: ru To: devel-distro@lists.altlinux.org References: <7e0e75a1-ccb8-b931-82c3-a1dcba02200e@altlinux.org> <20210902170921.GB20013@altlinux.org> <01ce3983-2315-5526-822c-654f56faca29@basealt.ru> <20210902181531.GA21170@altlinux.org> <20210902182057.GA21258@altlinux.org> <8a08d862-7f7c-225f-d612-4a5c07cb641d@basealt.ru> <20210902183348.GC21258@altlinux.org> From: Anton Farygin Organization: BaseALT In-Reply-To: <20210902183348.GC21258@altlinux.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel-distro] branding X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 18:35:45 -0000 Archived-At: List-Archive: 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 какими-то нужными им данными, не предполагающими обновления.