Аналогичный вопрос для всех веток - где-то должна быть информация о бранче.

Т.е. - вообще алгоритм работы нужен такой:
я поставил дистрибутив и обновляюсь из stable - у меня в /etc/os-release указан дистрибутив, источник обновления - имя stable бранча. В идеале ещё добавлять дату последней установки обновлений (или дату репозитория, из которого устанавливались обновления).

При переходе с ветки на ветки информация о том, что у меня установлен stable дистрибутив должна стать неактуальной. 

Кстати, в примерах: https://www.freedesktop.org/software/systemd/man/os-release.html

можно заводить свои поля, хотя на мой взгляд достаточно и существующих.

В файле os-release усть строка "CPE_NAME".

Для K Workstation эта строка судя по всемупрописана в пакете branding-xalt-kworkstation-release-*.

А где прописаны эти CPE для остальных продуктов?

У меня Сизиф, но брендинг стартеркита:

$ cat /etc/os-release 
NAME="starter kit"
VERSION="p10 (Hypericum)"
ID=altlinux
VERSION_ID=p10
PRETTY_NAME="ALT Starterkit (Hypericum)"
ANSI_COLOR="1;33"
CPE_NAME="cpe:/o:alt:starterkit:p10"
HOME_URL="http://en.altlinux.org/starterkits"
BUG_REPORT_URL="https://bugs.altlinux.org/"
BUILD_ID="starter kit p10 (Hypericum)"

Мы можем при сборке брендинга выставлять значение репозитория примерно так:
https://git.altlinux.org/gears/b/branding-alt-spserver.git?p=branding-alt-spserver.git;a=commitdiff;h=38c86798b07e325f26c2b0518278715be0998487;hp=3b61efbf752309f38fa2e5cd19ca3c28fb29c28e

в любых частях брендинга.
Но на e2k не работает
rpm --eval %_priority_distbranch

https://bugzilla.altlinux.org/44626

да, мне тоже нравится идея в os-release добавлять произвольное поле ALT_BRANCH_ID и в него записывать %_priority_distbranch
Только предлагаю это делать через branding пакеты, которые при сборке для бранча будут к себе записывать куда-то в бинарный пакет %_priority_distbranch

Тогда при обновлении с p10 до sisyphus этот самый бинарный пакет обновится и перепишет ALT_BRANCH_ID

Но нужно будет пересобирать эти пакеты после бранчевания.

Необходимо привести записи CPE_NAME в файле к одному виду и определиться с версионированием

Сейчас в стартеркитах докер-контейнерах написано:
CPE_NAME="cpe:/o:alt:starterkit:p10"

В СП8:
CPE_NAME="cpe:/o:alt:spserver:8.4"
CPE_NAME="cpe:/o:alt:spworkstation:8.4"

В Workstation K так:
CPE_NAME="cpe:/o:alt:kworkstation:10.1"

В Simply:
CPE_NAME="cpe:/o:alt:slinux:9.1"
CPE_NAME="cpe:/o:alt:slinux:10.1"


Предлагаю:
- Для стартеркитов (и осованных на них докер-образах) поменять поле версии р10 на 10. Насколько мне исвестно этот момент уже обсуждался с Антоном Мидюковым.
- Для обычных продуктов убрать минорную версию из СРЕ (10.1, 10.2,... -> 10)
- Для СП8 оставить как есть, т.к. 8.3 и 8.4 это разные продукты.

Корректность и единообразие СРЕ на самом деле важно для обеспечения однозначной идентификации целевой ОС при обработке информации об уязвимостях.

(Ответ для Danil Shein на комментарий #6)
> Необходимо привести записи CPE_NAME в файле к одному виду и определиться с
> версионированием
> 
> Сейчас в стартеркитах докер-контейнерах написано:
> CPE_NAME="cpe:/o:alt:starterkit:p10"
> 
> В СП8:
> CPE_NAME="cpe:/o:alt:spserver:8.4"
> CPE_NAME="cpe:/o:alt:spworkstation:8.4"
> 
> В Workstation K так:
> CPE_NAME="cpe:/o:alt:kworkstation:10.1"
> 
> В Simply:
> CPE_NAME="cpe:/o:alt:slinux:9.1"
> CPE_NAME="cpe:/o:alt:slinux:10.1"
> 
> 
> Предлагаю:
> - Для стартеркитов (и осованных на них докер-образах) поменять поле версии
> р10 на 10. Насколько мне исвестно этот момент уже обсуждался с Антоном
> Мидюковым.

Да. Но давайте уточним. Сейчас версия p10 у пакета, так что
VERSION=p10
VERSION_ID=p10
Будет ли достаточно поменять p10 -> 10 только в cpe? Или лучше поменять и VERSION с VERSION_ID.

> - Для обычных продуктов убрать минорную версию из СРЕ (10.1, 10.2,... -> 10)
> - Для СП8 оставить как есть, т.к. 8.3 и 8.4 это разные продукты.

А для СП, который будет на репозитории c10f1, а потом с10f2?
Сейчас там так:

ALT SP Workstation:

NAME="ALT SP Workstation"
VERSION="10"
ID=altlinux
VERSION_ID=10
PRETTY_NAME="ALT SP Workstation 11100-01"
ANSI_COLOR="1;33"
CPE_NAME="cpe:/o:alt:spworkstation:10"
HOME_URL="https://basealt.ru/"

и

ALT SP Server:

NAME="ALT SP Server"
VERSION="10"
ID=altlinux
VERSION_ID=10
PRETTY_NAME="ALT SP Server 11100-01"
ANSI_COLOR="1;33"
CPE_NAME="cpe:/o:alt:spserver:10"
HOME_URL="https://basealt.ru/"

(Ответ для Anton Farygin на комментарий #5)
> Но нужно будет пересобирать эти пакеты после бранчевания.
Перед выходом первых продуктов на новом бранче, они так или иначе пересоберутся.

> %_priority_distbranch
Облом. Он есть в rpm, но отсутствует в rpm-build.

(Ответ для Sergey V Turchin на комментарий #9)
> > %_priority_distbranch
> Облом. Он есть в rpm, но отсутствует в rpm-build.

%define BRANCH $(rpm --eval %_priority_distbranch)

(Ответ для Антон Мидюков на комментарий #10)
> %define BRANCH $(rpm --eval %_priority_distbranch)
Пейздесь кофе. Ну, придётся. ;-)

@ldv - нам очень нужен бранч в rpm-build. Без извращений.

(In reply to Anton Farygin from comment #12)
> @ldv - нам очень нужен бранч в rpm-build. Без извращений.

$ hsh-run -- rpm --showrc |grep branch
-14: _priority_distbranch	sisyphus
$ hsh-run -- rpmbuild --showrc |grep branch
-14: _priority_distbranch	sisyphus

(Ответ для Dmitry V. Levin на комментарий #13)
> $ hsh-run -- rpmbuild --showrc |grep branch
> -14: _priority_distbranch	sisyphus
Так, но
ошибка: Macro %_priority_distbranch not found
на этой же системе.
Или без hsh-run это не работает?

(Ответ для Dmitry V. Levin на комментарий #13)
> (In reply to Anton Farygin from comment #12)
> > @ldv - нам очень нужен бранч в rpm-build. Без извращений.
> 
> $ hsh-run -- rpm --showrc |grep branch
> -14: _priority_distbranch	sisyphus
> $ hsh-run -- rpmbuild --showrc |grep branch
> -14: _priority_distbranch	sisyphus


Как так ?
$ rpmbuild --showrc|grep  priority_distbranch|wc -l
0
$ rpm --showrc|grep  priority_distbranch
-14: _priority_distbranch       sisyphus
В hasher тоже не работает:
[builder@localhost .in]$ rpmbuild --showrc|grep  priority_distbranch|wc -l
0
$ hsh-run --  rpmbuild --showrc|grep  branch|wc -l
0
$ hsh-run --  rpm --showrc|grep  branch|wc -l
1

$ hsh-run -- rpmquery -f /usr/lib/rpm/macros.d/altlinux-release
altlinux-release-sisyphus-20201124-alt1.noarch

Пакет altlinux-release-$branch устанавливается в сборочную среду как при обычной сборке, так и при тестовой пересборке.

(Ответ для Dmitry V. Levin на комментарий #16)
> $ hsh-run -- rpmquery -f /usr/lib/rpm/macros.d/altlinux-release
> altlinux-release-sisyphus-20201124-alt1.noarch
LOL

(Ответ для Dmitry V. Levin на комментарий #13)
> > @ldv - нам очень нужен бранч в rpm-build. Без извращений.
> $ hsh-run -- rpm --showrc |grep branch
> -14: _priority_distbranch	sisyphus
> $ hsh-run -- rpmbuild --showrc |grep branch
> -14: _priority_distbranch	sisyphus
Без изврата это не работает.
https://git.altlinux.org/tasks/312542/gears/200/git?p=git;a=commitdiff;h=8e3fa1e966bf1d0f03d1eb4a6f971dc398ceda08

(Ответ для Sergey V Turchin на комментарий #18)
> (Ответ для Dmitry V. Levin на комментарий #13)
> > > @ldv - нам очень нужен бранч в rpm-build. Без извращений.
> > $ hsh-run -- rpm --showrc |grep branch
> > -14: _priority_distbranch	sisyphus
> > $ hsh-run -- rpmbuild --showrc |grep branch
> > -14: _priority_distbranch	sisyphus
> Без изврата это не работает.
> https://git.altlinux.org/tasks/312542/gears/200/git?p=git;a=commitdiff;
> h=8e3fa1e966bf1d0f03d1eb4a6f971dc398ceda08

А в сборочнице то работает, так как там приоритет у altlinux-release-$branch при инициализации hasher.
На самом деле это же здорово! Если пакет собрали не на сборочнице, то %_priority_distbranch будет текстом. Дополнительная защита от подделки (защита от честных людей и самого себя). В случае брендингов это же очень хорошо.

(Ответ для Антон Мидюков на комментарий #19)
> > Без изврата это не работает.
> > https://git.altlinux.org/tasks/312542/gears/200/git?p=git;a=commitdiff;
> > h=8e3fa1e966bf1d0f03d1eb4a6f971dc398ceda08
> А в сборочнице то работает
Ну, ладно. Я себе костыль сделал.

(In reply to Антон Мидюков from comment #19)
> А в сборочнице то работает, так как там приоритет у altlinux-release-$branch
> при инициализации hasher.

В локальном хэшере при установки приоритета для altlinux-release-sisyphus в Сизифе у меня тоже работает. А вот для p10 все равно нет, т.к. в altlinux-release-p10 не задается %_priority_distbranch.

(Ответ для Mikhail Efremov на комментарий #21)
> (In reply to Антон Мидюков from comment #19)
> > А в сборочнице то работает, так как там приоритет у altlinux-release-$branch
> > при инициализации hasher.
> 
> В локальном хэшере при установки приоритета для altlinux-release-sisyphus в
> Сизифе у меня тоже работает. А вот для p10 все равно нет, т.к. в
> altlinux-release-p10 не задается %_priority_distbranch.

Действительно. Нужно исправить altlinux-release-p10.

(Ответ для Антон Мидюков на комментарий #22)
> (Ответ для Mikhail Efremov на комментарий #21)
> > (In reply to Антон Мидюков from comment #19)
> > > А в сборочнице то работает, так как там приоритет у altlinux-release-$branch
> > > при инициализации hasher.
> > 
> > В локальном хэшере при установки приоритета для altlinux-release-sisyphus в
> > Сизифе у меня тоже работает. А вот для p10 все равно нет, т.к. в
> > altlinux-release-p10 не задается %_priority_distbranch.
> 
> Действительно. Нужно исправить altlinux-release-p10.

[#318341] p10 EPERM (try 3) altlinux-release-p10.git=20210721-alt2

(Ответ для Антон Мидюков на комментарий #23)
> (Ответ для Антон Мидюков на комментарий #22)
> > (Ответ для Mikhail Efremov на комментарий #21)
> > > (In reply to Антон Мидюков from comment #19)
> > > > А в сборочнице то работает, так как там приоритет у altlinux-release-$branch
> > > > при инициализации hasher.
> > > 
> > > В локальном хэшере при установки приоритета для altlinux-release-sisyphus в
> > > Сизифе у меня тоже работает. А вот для p10 все равно нет, т.к. в
> > > altlinux-release-p10 не задается %_priority_distbranch.
> > 
> > Действительно. Нужно исправить altlinux-release-p10.
> 
> [#318341] p10 EPERM (try 3) altlinux-release-p10.git=20210721-alt2

Пришло в p10. Можно использовать.

(In reply to Danil Shein from comment #6)
> - Для обычных продуктов убрать минорную версию из СРЕ (10.1, 10.2,... -> 10)

Почему? Из спецификации CPE это совсем не следует. Напротив, в примерах именно полная версия, а не ее часть.

(In reply to Anton Farygin from comment #5)
> да, мне тоже нравится идея в os-release добавлять произвольное поле
> ALT_BRANCH_ID и в него записывать %_priority_distbranch
> Только предлагаю это делать через branding пакеты, которые при сборке для
> бранча будут к себе записывать куда-то в бинарный пакет %_priority_distbranch

Мне не сложно добавить ALT_BRANCH_ID, но хотелось бы понимать, действительно ли это кому-то надо и где и для чего это используется. Также следует учитывать, что это поле будет отражать только тот факт, что в системе скорее всего стоит branding, собранный для указанного бранча и больше ничего. Какие пакеты и откуда еще там установлены, что написано в apt source.list и т.п. - все это так же неизвестно.

Задание с исправленным /etc/os-release в брендинге стартеркитов ушло в p10:

[#320276] p10 DONE (try 2) branding-alt-starterkit.git=10-alt3

На данный момент ALT_BRANCH_ID внедрён в os-release следующих брендингов:
branding-xalt-kworkstation
branding-alt-spserver
branding-alt-spworkstation
branding-alt-starterkit
branding-alt-sisyphus
branding-alt-mobile-sisyphus

А что должно быть в NAME написано?

Только у kworkstation:
NAME="ALT"

У других дистрибутивов имя дистрибутива:
NAME="Simply Linux"
NAME="ALT Education"
NAME="ALT Server"
NAME="ALT Virtualization"
NAME="ALT Mobile"
NAME="ALT Mobile Sisyphus"

У регулярок:
NAME="Sisyphus"

У стартеркитов:
NAME="starter kit"

То есть выбиваются из общей канвы kworkstation, стартеркиты и регулярки.

(Ответ для Антон Мидюков на комментарий #29)
> А что должно быть в NAME написано?
> Только у kworkstation:
> NAME="ALT"
Мне другой информации пока не поступало. Может, есть тайное общество именователей, но я в нём не состою.

> У других дистрибутивов
У меня есть мнение, что это костыли.

2 Shaba: прошу уточнить.

По поводу os-release. Уже слишком много наколхозили все самостоятельно. Но man os-release видимо читали плохо.
Я могу высказать только свои пожелания, т.к. не мантейнер пакета alt-os-release.
1) NAME="ALT Linux" для всех
2) PRETTY_NAME индивидуально для разных дистрибутивов
3) VARIANT="Workstation Edition", VARIANT_ID=workstation - индивидуально для разных дистрибутивов.

(Ответ для Alexey Shabalin на комментарий #31)
> По поводу os-release. Уже слишком много наколхозили все самостоятельно. Но
> man os-release видимо читали плохо.
> Я могу высказать только свои пожелания, т.к. не мантейнер пакета
> alt-os-release.
> 1) NAME="ALT Linux" для всех

Значит, никто не угадал, и всем нужно переделать.
Все согласны с таким NAME?

(Ответ для Антон Мидюков на комментарий #32)
> (Ответ для Alexey Shabalin на комментарий #31)
> > 1) NAME="ALT Linux" для всех
> Значит, никто не угадал,
Я угадал в любом случае, т.к. мой вариант был определён тоже Алексеем.

> и всем нужно переделать.
> Все согласны с таким NAME?
Я не против, но подозреваю, что оно менее универсальное, чем "ALT".

(Ответ для Alexey Shabalin на комментарий #31)
> 3) VARIANT="Workstation Edition", VARIANT_ID=workstation
Прошу Евгения, как автора изменения в alt-os-release, прояснить
Будет ли корректно для Рабочей станции К:
VARIANT="Workstation Edition", VARIANT_ID=kworkstation
?

Прошу Евгения, как автора добавления VARIANT и VARIANT_ID в  alt-os-release привести примеры для всех дистрибутивов по возможности, чтобы избежать такого бардака, как сейчас.

На текущий момент, видимо, более правильно будет указать так:
VARIANT="Workstation K", VARIANT_ID=edition_kworkstation

В целом, если редакции не предусмотрены, то эти опции можно не указывать.
Редакции необходимы для их использования при отображении компонентов, как
перечня сопровождаемой в рамках продукта пакетной базы.

Далее можно вчитываться, по желанию.
Если ничего не делать, то предполагается определённая обратная совместимость.
__________________________

Более развёрнуто для чего это нужно?

Для определения текущей редакции и задания другой редакции из доступных. Если в дистрибутиве не предусмотрено несколько редакций, то эта возможность (указание редакции в /etc/os-release и dconf'е /etc/dconf/db/default.d/99-edition) нужна только для определения информации о текущей редакции по умолчанию.

Получение информации о текущей редакции, что влияет на список компонентов из которых состоит продукт, как набор компонент, отображаемых в alteratorctl или alt-components. Если редакция не указана, то отображаются все доступные компоненты.

Список компонент, входящих в редакцию определяет пакетную базу сопровождаемую в рамках продукта. А перечень пакетов, определяется описанием продукта, как набора компонент:

$ alteratorctl editions info edition_domain | head -n20
type = "Edition"
name = "edition_domain"
display_name.en = "ALT Domain"
display_name.ru = "Альт Домен"

license = "ALT_Domain_License/11.0"
arches = [ "x86_64", "aarch64" ]

desktop_environment = "GNOME"
kflavours = { default = "6.12", options = [ "6.6", "6.12" ] }
languages = { default = "ru", options = [ "ru", "en" ] }

[sections.base]
display_name.en = "Base components"
display_name.ru = "Базовые компоненты"
components = [
# system/brandings:
    "branding-alt-server",
# system/boot:
    "firmware",

Все эти описания собираются в рамках пакета alt-components-base:

$ rpm -q alt-components-base 
alt-components-base-0.8.0-alt1.noarch

$ rpm -q alt-editions-server --queryformat="%{SOURCERPM}\n"
alt-components-base-0.8.0-alt1.src.rpm

Опция license определяет каталог с файлами лицензии "/usr/share/distro-licenses/" + license:

$ rpm -ql distro-licenses | grep ALT_Domain_License/11.0
/usr/share/distro-licenses/ALT_Domain_License/11.0
/usr/share/distro-licenses/ALT_Domain_License/11.0/distbranch.list
/usr/share/distro-licenses/ALT_Domain_License/11.0/license.all.html
/usr/share/distro-licenses/ALT_Domain_License/11.0/license.ru.html
/usr/share/distro-licenses/ALT_Domain_License/11.0/target.list

$ sudo alterator-cmdline /notes action read

url:/usr/share/distro-licenses/ALT_Server_License/11.0/license.all.html

Текст лицензии и описание редакции могут быть получены напрямую из интерфейса.

________________

Подробнее про интерфейс.

Префикс edition_ нужен для того, чтобы избежать потенциального пересечения по именам объектов на шине. Дело в том, что alterator-manager и alterator-module-executor пока ещё не умеют полноценно в дерево. Хотя интерфейсы у объектов разные и конфликт, в общем случае, крайне маловероятен.

Предполагается, что VARIANT_ID может быть использован для обращения за информацией о продукте.


Методы для интерфейса org.altlinux.alterator.edition1, имя объекта формируется как "/org/altlinux/alterator/" + VARIANT_ID:

$ busctl call org.altlinux.alterator /org/altlinux/alterator/edition_domain org.altlinux.alterator.edition1 
Description  Info         License      

Методы для глобального интерфейса org.altlinux.alterator.current_edition1 позволяют вычислить текущую выбранную редакцию или задать другую, предварительно показав (или не показав) лицензию:

$ busctl call org.altlinux.alterator /org/altlinux/alterator/global org.altlinux.alterator.current_edition1 
Description  Get          Info         License      Set
$ busctl call org.altlinux.alterator /org/altlinux/alterator/global org.altlinux.alterator.current_edition1 Get
asi 1 "edition_server" 0

Список всех доступных редакций вычисляется по перечню объектов на шине 

$ alteratorctl manager getobjects --system org.altlinux.alterator.edition1
<<< Объекты на системной шине:
/org/altlinux/alterator/edition_domain
/org/altlinux/alterator/edition_server

___________________

На уровне необходимых пакетов это выглядит так:

$ rpm -ql branding-alt-server-release 
/etc/altlinux-release
/etc/buildreqs/packages/ignore.d/alt-server-release
/etc/dconf/db/default.d/99-edition
/etc/fedora-release
/etc/redhat-release
/etc/system-release
/usr/lib/os-release

$ cat /etc/dconf/db/default.d/99-edition
[org/altlinux/product/edition]
current='edition_server'

$ rpm -qR branding-alt-server-release 
alt-os-release
alt-editions-server
rpmlib(PayloadIsLzma)

$ rpm -ql alt-editions-server
/usr/share/alterator/editions
/usr/share/alterator/editions/edition_domain
/usr/share/alterator/editions/edition_domain/description.html
/usr/share/alterator/editions/edition_domain/description.ru.html
/usr/share/alterator/editions/edition_domain/edition_domain.edition
/usr/share/alterator/editions/edition_server
/usr/share/alterator/editions/edition_server/description.html
/usr/share/alterator/editions/edition_server/description.ru.html
/usr/share/alterator/editions/edition_server/edition_server.edition

Значение VARIANT_ID, по умолчанию, из os-release продублировано в /etc/dconf/db/default.d/99-edition (см. выше). Это важно для отображения в инструментах и динамического переключения между редакциями.

Интерфейс для редакции автоматически создаётся во время установки через файл-триггер:

$ cat /etc/alterator/backends/autogenerated-edition-edition_domain.backend
type = "Backend"
module = "executor"
name = "edition_domain"
interface = "edition1"

[methods.Info]
execute = "/usr/lib/alterator-backend-edition/edition_helper.py info edition_domain"
stdout_bytes = true

[methods.Description]
execute = "/usr/lib/alterator-backend-edition/edition_helper.py description edition_domain"
stdout_bytes = true
environment.LC_ALL = {}

[methods.License]
execute = "/usr/lib/alterator-backend-edition/edition_helper.py license edition_domain"
stdout_bytes = true
environment.LC_ALL = {}

$ grep editions -R /usr/lib/rpm
/usr/lib/rpm/10-alterator-backend-edition.filetrigger:if grep -qs '^/usr/share/alterator/editions'; then
/usr/lib/rpm/10-alterator-backend-edition.filetrigger:	/usr/lib/alterator-backend-edition/generate-editions-backends

_______________________

На уровне зависимостей брендинг с /etc/os-release никак не зависит от бекенда и тащит только описание с редакциями и компонентами:

$ rpm -qR branding-alt-server-release 
alt-os-release
alt-editions-server
rpmlib(PayloadIsLzma)

$ rpm -qR alt-editions-server
alt-components-base = 0.8.0-alt1
rpmlib(PayloadIsLzma)

$ rpm -qR alt-components-base
rpmlib(PayloadIsLzma)

(Ответ для Sergey V Turchin на комментарий #33)
> (Ответ для Антон Мидюков на комментарий #32)
> > (Ответ для Alexey Shabalin на комментарий #31)
> > > 1) NAME="ALT Linux" для всех
> > Значит, никто не угадал,
> Я угадал в любом случае, т.к. мой вариант был определён тоже Алексеем.
> 
> > и всем нужно переделать.
> > Все согласны с таким NAME?
> Я не против, но подозреваю, что оно менее универсальное, чем "ALT".

shaba@ таки за ALT Linux. Я начал свои брендинги исправлять на "ALT Linux".

(Ответ для Антон Мидюков на комментарий #37)
> shaba@ таки за ALT Linux. Я начал свои брендинги исправлять на "ALT Linux".
Ок, исправлю на "ALT Linux".

(Ответ для Evgeny Sinelnikov на комментарий #36)
> VARIANT="Workstation K", VARIANT_ID=edition_kworkstation
Предлагаю не маслить масло. VARIANT_ID=kworkstation

https://www.freedesktop.org/software/systemd/man/latest/os-release.html#VARIANT_ID=

(Ответ для Антон Мидюков на комментарий #37)
> "ALT Linux".
Я не против, но никого не смущает, что это будет расходиться с официальным названием?

Все начнут называть "ALT Server" как "ALT Linux Server" и "ALT Education" как "ALT Linux Education". Особенно интересно, что при попытке поправить вы будете посланы в место, где система именно так показала.

(Ответ для Антон Мидюков на комментарий #37)
> Я начал свои брендинги исправлять на "ALT Linux".
Стартеркиты -- понятное дело.

(Ответ для Sergey V Turchin на комментарий #40)
> > "ALT Linux".
> Я не против
Хотя, буду против, пока это не проанализируют в достаточной степени, чтобы официально принять.

Created attachment 18527 [details]
os-release-name-check.sh

(Ответ для Sergey V Turchin на комментарий #43)
> Создано вложение 18527 [details] [подробности]
> os-release-name-check.sh

В скрипте логическая ошибка. В этом смысловом ряду должно быть не $NAME, а $PRETTY_NAME.

(Ответ для Антон Мидюков на комментарий #44)
> В этом смысловом ряду должно быть не $NAME, а $PRETTY_NAME.
Это и есть ошибка.
https://www.freedesktop.org/software/systemd/man/latest/os-release.html
Если обратите внимание, то там в NAME указано "Fedora", а не "Fedora Project" и не "Fedora Linux".

Другое дело, что в VARIANT тоже не совсем понятно, т.к. в comment#36 Женин вариант совсем не соответствует примеру из документации.

(Ответ для Sergey V Turchin на комментарий #45)
> (Ответ для Антон Мидюков на комментарий #44)
> > В этом смысловом ряду должно быть не $NAME, а $PRETTY_NAME.
> Это и есть ошибка.
> https://www.freedesktop.org/software/systemd/man/latest/os-release.html
> Если обратите внимание, то там в NAME указано "Fedora", а не "Fedora
> Project" и не "Fedora Linux".

Я не увидел в документации строку:
NAME VARIANT VERSION

Откуда скрипт?

(Ответ для Антон Мидюков на комментарий #47)
> Я не увидел в документации строку:
> NAME
Там есть "Fedora" и "fedoraprpject".

(Ответ для Антон Мидюков на комментарий #47)
> Откуда скрипт?
Из совсем другого сообщения.

(Ответ для Антон Мидюков на комментарий #47)
> Я не увидел в документации строку:
> NAME VARIANT VERSION
Не суть. В kinfocenter, например, по умолчанию показывается NAME VERSION.

https://git.altlinux.org/gears/k/kinfocenter.git?p=kinfocenter.git;a=blob_plain;f=alt-use-pretty-name.patch
А исходя из этого у нас и BUILD_ID кривой.

Created attachment 18542 [details]
умолчательный kinfocenter

Вот так непатченый kinfocenter будет показывать сейчас Рабочую станцию K.

Поступила информация, что "ALT Linux не существует". ;-) https://t.me/alt_smokeroom/282969

Created attachment 18939 [details]
Предупреждение о левых дополнениях

Вот ещё пример использование NAME в системе.

(Ответ для Sergey V Turchin на комментарий #53)
> Создано вложение 18939 [details] [подробности]
> Предупреждение о левых дополнениях
> 
> Вот ещё пример использование NAME в системе.

А они точно NAME смотрят? Правильный способ смотреть ID. А уж текст любой может быть.

(Ответ для Антон Мидюков на комментарий #54)
> А они точно NAME смотрят?
Другого такого текста у меня в os-release нет.

(Ответ для Антон Мидюков на комментарий #54)
> Правильный способ смотреть ID. А уж текст любой может быть.
Неправильный, т.к. "любой текст" там будет криво смотреться.

(Ответ для Антон Мидюков на комментарий #54)
> А они точно NAME смотрят?
Проверил, точно его.

(Ответ для Sergey V Turchin на комментарий #57)
> (Ответ для Антон Мидюков на комментарий #54)
> > А они точно NAME смотрят?
> Проверил, точно его.

И как оно себя с брендингом alt-education ведёт?
NAME="ALT Education"

(Ответ для Антон Мидюков на комментарий #58)
> NAME="ALT Education"
Соответственно, на всех скриншотах будет "ALT Education" вместо "ALT"

Думаю, сначала надо определится, как у нас называется ОС.
Она одна разных видов или их несколько разных?

(Ответ для Sergey V Turchin на комментарий #60)
> Думаю, сначала надо определится, как у нас называется ОС.
> Она одна разных видов или их несколько разных?

ОС у нас точно одна. ID у неё altlinux. Осталось определиться, как она называется. ALT или ALT Linux. shaba@ предложил называть ALT Linux:
https://bugzilla.altlinux.org/show_bug.cgi?id=45743#c31

(Ответ для Sergey V Turchin на комментарий #50)
> (Ответ для Антон Мидюков на комментарий #47)
> > Я не увидел в документации строку:
> > NAME VARIANT VERSION
> Не суть. В kinfocenter, например, по умолчанию показывается NAME VERSION.
> 
> https://git.altlinux.org/gears/k/kinfocenter.git?p=kinfocenter.git;
> a=blob_plain;f=alt-use-pretty-name.patch
> А исходя из этого у нас и BUILD_ID кривой.

Что мешает поправить, чтобы показывалось PRETTY_NAME VERSION?
NAME - название ОС, PRETTY_NAME - название дистрибутива.

(Ответ для Антон Мидюков на комментарий #61)
> ALT или ALT Linux
Я с этим согласен. Можно ALT для официальных дистрибутивов, а ALT Linux для остальных сборок.
Если только один, то ALT.
Осталось, чтоб остальные подтянулись.

> Что мешает поправить, чтобы показывалось PRETTY_NAME VERSION?
Потому, что наш путь костылей и подпорок мне не нравится и подзадолбал уже за многие годы.
Я уже закостылил kinfocenter, но больше не хочется.

А для Simply Linux что предлагается в NAME, тоже ALT? Просто SL же называется именно "Simply Linux", а не "ALT Simply Linux". И NAME вообще не использовать в PRETTY_NAME?

(Ответ для Mikhail Efremov на комментарий #63)
> А для Simply Linux что предлагается в NAME, тоже ALT? Просто SL же
> называется именно "Simply Linux", а не "ALT Simply Linux". И NAME вообще не
> использовать в PRETTY_NAME?

NAME ALT Linux
PRETTY_NAME Simply Linux

(Ответ для Антон Мидюков на комментарий #64)
> NAME ALT Linux
> PRETTY_NAME Simply Linux

Тогда в BUILD_ID будет ерунда, там сейчас NAME VERSION.
Предполагалось, что в NAME все-таки имя дистрибутива (и только), а в PRETTY_NAME уже более подробная строка. В SL сейчас
NAME="Simply Linux"
PRETTY_NAME="Simply Linux 11.0 (Giuseppe)"
 
И вообще, если приходится патчить программы для отображения нашего os-release, то это скорее заничит, что в os-release что-то не так.

(Ответ для Mikhail Efremov на комментарий #63)
> А для Simply Linux что предлагается в NAME, тоже ALT? Просто SL же
> называется именно "Simply Linux", а не "ALT Simply Linux". И NAME вообще не
> использовать в PRETTY_NAME?
NAME="ALT"
PRETTY_NAME="Simply Linux NN.N (ABC)"
VARIANT="Simply"
VARIANT_ID=simply

(Ответ для Mikhail Efremov на комментарий #65)
> И вообще, если приходится патчить программы для отображения нашего
> os-release, то это скорее заничит, что в os-release что-то не так.
И я об этом. :-)

(Ответ для Sergey V Turchin на комментарий #66)
> (Ответ для Mikhail Efremov на комментарий #63)
> > А для Simply Linux что предлагается в NAME, тоже ALT? Просто SL же
> > называется именно "Simply Linux", а не "ALT Simply Linux". И NAME вообще не
> > использовать в PRETTY_NAME?
> NAME="ALT"
> PRETTY_NAME="Simply Linux NN.N (ABC)"
> VARIANT="Simply"
> VARIANT_ID=simply

Тогда уж VARIANT="Simply Linux" и использовать VARIANT VERSION в BUILD_ID при наличии VARIANT. В принципе, можно и так.

(Ответ для Mikhail Efremov на комментарий #68)
> использовать VARIANT VERSION в BUILD_ID при наличии VARIANT
Да, там одной версии хватит по сути.

> > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT
> Да, там одной версии хватит по сути.
Разве что, на случай изменения пакета брандинг-release на другой.

(Ответ для Sergey V Turchin на комментарий #70)
> > > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT
> > Да, там одной версии хватит по сути.
> Разве что, на случай изменения пакета брандинг-release на другой.

BUILD_ID у нас однозначно должен давать ответ на вопрос, какой брендинг был установлен изначально.

(Ответ для Антон Мидюков на комментарий #71)
> (Ответ для Sergey V Turchin на комментарий #70)
> > > > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT
> > > Да, там одной версии хватит по сути.
> > Разве что, на случай изменения пакета брандинг-release на другой.
> 
> BUILD_ID у нас однозначно должен давать ответ на вопрос, какой брендинг был
> установлен изначально.

Ну да, нужно знать какой дистрибутив был установлен.
Нужно еще и файлтриггер в alt-os-release переделать на использование VARIANT.
Я сделаю тогда, будет VARIANT VERSION при наличии VARIANT, иначе NAME VERSION как раньше.

(Ответ для Mikhail Efremov на комментарий #72)
> (Ответ для Антон Мидюков на комментарий #71)
> > (Ответ для Sergey V Turchin на комментарий #70)
> > > > > использовать VARIANT VERSION в BUILD_ID при наличии VARIANT
> > > > Да, там одной версии хватит по сути.
> > > Разве что, на случай изменения пакета брандинг-release на другой.
> > 
> > BUILD_ID у нас однозначно должен давать ответ на вопрос, какой брендинг был
> > установлен изначально.
> 
> Ну да, нужно знать какой дистрибутив был установлен.
> Нужно еще и файлтриггер в alt-os-release переделать на использование VARIANT.
> Я сделаю тогда, будет VARIANT VERSION при наличии VARIANT, иначе NAME
> VERSION как раньше.

В большинстве брендингов BUILD_ID уже написан изначально, его не приходится генерировать.

(Ответ для Антон Мидюков на комментарий #73)
> В большинстве брендингов BUILD_ID уже написан изначально, его не приходится
> генерировать.

Да, но учесть возможность все равно надо.

А ещё:

$ lsb_release -a
LSB Version:    n/a
Distributor ID: ALT
Description:    ALT Workstation K 11.1 (Nemorosa)
Release:        11.1
Codename:       Nemorosa

Для удобства перевода имени дистрибутива на английский PRETTY_NAME надо сделать генерируемым из NAME + VARIANT + VERSION_ID + (если хочется) VERSION_CODENAME

NAME = ALT
VERSION_ID = 11.2
VARIANT = Workstation


всё  в соответствии со стандартом
https://www.freedesktop.org/software/systemd/man/latest/os-release.html

(Ответ для Sergey V Turchin на комментарий #75)
> А ещё:
> 
> $ lsb_release -a
> LSB Version:    n/a
> Distributor ID: ALT
> Description:    ALT Workstation K 11.1 (Nemorosa)
> Release:        11.1
> Codename:       Nemorosa

а что такое lsb version ?

(Ответ для Anton Farygin на комментарий #77)
> > А ещё:
> > $ lsb_release -a
> > LSB Version:    n/a
> а что такое lsb version ?
/etc/lsb-release, но LSB сам с каждым днём всё дохлее и дохлее.

Created attachment 21133 [details]
Гайд как заполнить свой os-release

Доброго времени суток. Увидел что по итогу не пришли к какому-то конечному решению, ну или как минимум не сформировали его в виде пошагового гайда "Как заполнить свой os-release", осмелюсь предложить свой вариант.

(Ответ для Semen Fomchenkov на комментарий #79)
> Создано вложение 21133 [details] [подробности]
> Гайд как заполнить свой os-release
?

(Ответ для Sergey V Turchin на комментарий #80)
> (Ответ для Semen Fomchenkov на комментарий #79)
> > Создано вложение 21133 [details] [подробности]
> > Гайд как заполнить свой os-release
> ?
Юникод в вопросики превращает. :-)
Мне только добавить VERSION_CODENAME и RELEASE_TYPE, делаю.

Вот как раз RELEASE_TYPE у меня вызывает вопросы. Вот установил пользователь релиз дистрибутива X.0, при этом RELEASE_TYPE=stable или lts, все ок. Но при подготовке нового минорного релиза Х.1 в брендинге будет же RELEASE_TYPE=development или вообще experiment, что и приедет всем пользователям.

(Ответ для Mikhail Efremov на комментарий #82)
> Вот как раз RELEASE_TYPE у меня вызывает вопросы. Вот установил пользователь
> релиз дистрибутива X.0, при этом RELEASE_TYPE=stable или lts, все ок. Но при
> подготовке нового минорного релиза Х.1 в брендинге будет же
> RELEASE_TYPE=development или вообще experiment, что и приедет всем
> пользователям.

Не надо в стабильный репозиторий собирать брендинг для beta. Такой брендинг должен жить в задании.

(Ответ для Антон Мидюков на комментарий #83)
> Не надо в стабильный репозиторий собирать брендинг для beta. Такой брендинг
> должен жить в задании.
+1

Мне очень нравится идея подобной стандартизаци. Но у меня есть из любопытства вопрос: как быть с ALT Atomic? Из-за другого пакетного менеджера и спрятанного apt-get, он не совсем совместим классическими дистрибутивами ALT. Я исходя из этого NAME сделал так (пакет нет смысла кидать, так как файл меняется при создании образа):

BUG_REPORT_URL="https://altlinux.space/alt-atomic/onyx/issue"
IMAGE_VERSION="20260415-nightly"
ID_LIKE="altlinux"
PRETTY_NAME="ALT Atomic Onyx Nightly"
LOGO="alt-atomic"
VENDOR_NAME="ALT Linux Team"
DEFAULT_HOSTNAME="alt-atomic"
VARIANT="Default"
NAME="ALT Atomic"
RELEASE_TYPE="development"
HOME_URL="https://atomic.alt-gnome.ru/"
DOCUMENTATION_URL="https://atomic.alt-gnome.ru/"
BUILD_ID="Default 20260415-nightly"
IMAGE_ID="alt-atomic-onyx-nightly"
ID="alt-atomic-onyx-nightly"
VERSION_ID="20260415-nightly"
ANSI_COLOR="1;33"
CPE_NAME="cpe:/o:alt:atomic:onyx:nightly:20260415"
ALT_BRANCH_ID="sisyphus"
VENDOR_URL="https://altlinux.org/"
VARIANT_ID="default"
VERSION="15.04.2026 Nightly"

Насколько всё это корректно, если опираться на новый вектор?

(Ответ для Vladimir Romanov на комментарий #85)
> Мне очень нравится идея подобной стандартизаци. Но у меня есть из
> любопытства вопрос: как быть с ALT Atomic? Из-за другого пакетного менеджера
> и спрятанного apt-get, он не совсем совместим классическими дистрибутивами
> ALT. Я исходя из этого NAME сделал так (пакет нет смысла кидать, так как
> файл меняется при создании образа):

Касательно VARIANT, Onyx не совсем корректно подойдет, так как образы собираются в нескольких вариантах. Стоит ли сделать

NAME: ALT Atomic
VARIANT: Onyx (Nvidia)
VERSION: 20260222 Nightly

, чтобы подходить под условия выше?